Este muerto está muy vivo

Es muy posible que todos hayan oído hablar de la polémica iniciada por Alberto Savoia y James Whittaker con el motto “Test is Dead”. La primera referencia que tuve sobre este tema fue el vídeo de la conferencia, extremadamente interesante y amena, que Savoia dio en el GTAC (Google Test Automation Conference) del año 2011. Para los que no la hayan visto, Alberto proclama que estamos en la era que él denomina “post-agile”, caracterizada porque las empresas buscan productos de software que tengan éxito utilizando ciclos de desarrollo muy cortos, entregas muy frecuentes y midiendo la respuesta de los usuarios ante las características del software.

En este contexto razona que es preferible dedicar todos los recursos disponibles a la búsqueda del producto correcto y no a prevenir que el software tenga fallos o no. En teoría, las técnicas que permiten medir la respuesta de los usuarios también permitirían conocer los fallos que puedan existan en el comportamiento del software. Por tanto y tras recibir esa información directamente de los usuarios, se podría dar solución a los problemas en las próximas versiones o, incluso y si se considera necesario, podría cambiarse sobre la marcha la versión en producción.

Un ejemplo de producto en el que la empresa se habría centrado en la búsqueda del producto correcto (build the right it) en lugar de construir el software correctamente (build it right) es Twitter. Durante meses, o años, se hizo famosa la ballena que anunciaba que Twitter tenía problemas de rendimiento y no podías utilizarlo. Para el equipo de desarrollo, en un momento en que su producto estaba atrayendo muchos usuarios y con un tráfico creciente, habría sido entonces más importante desarrollar nuevas características que atraigan a los usuarios que hacer pruebas de rendimiento o dimensionar los servidores.

Por tanto, siguiendo una estrategia alineada con la filosofía “lean”, podemos lanzar un producto software al mercado e ir haciendo cambios sobre la marcha frecuentemente, recogiendo información de nuestros clientes que nos indique si desean el producto y analizando qué nuevas características debemos implementar. Los propios clientes también pueden decirnos qué fallos hay en el software y éstos podrían ser corregidos en un lapso muy corto de tiempo. Por tanto ¿para qué necesitamos testers? El testing ha muerto. Test is dead.

Estoy de acuerdo con muchas de las afirmaciones realizadas por Alberto y James y, en realidad, creo que solo hay un aspecto en el que disiento de ellos. El caso es que me parece un aspecto fundamental que derrumba, en mi opinión, la teoría de la muerte del testing y hace que ese muerto siga muy vivo. En la propia conferencia del GTAC 2011, la primera pregunta que se hizo a Alberto Savoia fue si estaría dispuesto a que le transplantaran un corazón artificial controlado por software que no hubiera sido probado. Su respuesta fue que no, y que quedaban ciertos productos para los que su enfoque no encajaba. En su opinión el porcentaje de productos a los que no se puede aplicar es minoritaria. Yo no estoy de acuerdo.

Los recursos a dedicar a las pruebas de cada producto deben ser proporcionales a la criticidad del software que se está probando. Obviamente no dedicamos los mismos recursos a la prueba del software que controla un avión que al método que totaliza el número de retweets en una red social. No es lo mismo que falle uno o que falle otro, no provoca los mismos efectos. ¿Puede Twitter permitirse sacar una nueva versión y que el número de retweets de todos los tweets pase a ser cero? Bueno, no morirá nadie si eso pasa y de hecho es algo que ya ha sucedido. Pero tampoco es gratis que suceda. ¿Hay ciertas funcionalidades o incluso productos completos en los que podemos tomar la decisión de sacar versiones a producción sin haber dedicado apenas recursos a probarlos? Sí, con matices pero sí. En los momentos en que se está intentando posicionar un nuevo producto en el mercado puede ser incluso ventajoso hacerlo, como ya se ha mencionado. Pero, y éste es un gran pero ¿es este supuesto aplicable a la inmensa mayoría del software con el que trabajamos día a día? En mi opinión no, rotundamente. Y no estoy hablando ahora ya de controlar aviones o de aplicaciones eHealth, que también pero, si me lo permiten… preferiría que esos métodos no se utilizaran con el software que da la orden de que se pague mi nómina todos los meses o calcula lo que debo pagar en mi próxima declaración de Hacienda.

Larga vida al testing.

Referencias:

–          GTAC 2011: Opening Keynote Address – Test is Dead. https://www.youtube.com/watch?v=X1jWe5rOu3g

–          Eric Ries. “The Lean Startup: How Constant Innovation Creates Radically Successful Businesses”. 2011.

 

Más información:

jose garcia faijul

José García-Fanjul
Profesor de la Universidad de Oviedo
Email:
jgfanjul@uniovi.esTwitter: @jgfanjul

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s