El verdadero valor del Testing

Una de las cosas que más me gustan de Agile es su foco en el Valor. Hace poco alguien me envió un link a un blog de Google sobre End-to-End testing donde se decía: “Un test fallido no beneficia directamente al usuario”. El valor solo se crea cuando el bug está arreglado.

Con frecuencia, las estrategias de prueba identifican normalmente varios tipos de test (a veces representado en forma de ‘Pirámide de Prueba’) y ponen el foco en identificar los componentes del sistema/software que representan el mayor riesgo y ajustan el enfoque de prueba y las actividades para ese fin y eso es todo. ¡Fin! ¡Sabemos cómo encontrar errores de manera más efectiva! A partir de entonces, depende de los desarrolladores arreglarlo.

¡Esto es un error! Sólo encontrar errores no aporta ningún valor al usuario final. Entonces, ¿deberíamos dejarlo así? No, no lo creo, pero deberíamos ser más conscientes de dónde, cuándo y cómo las pruebas proporcionan valor. Las pruebas son fundamentales para implementar soluciones libres de errores (bug-poor 😉 solutions). Encontrar los errores es simplemente el primer paso. El análisis de la causa raíz y la corrección de errores son los siguientes pasos y sin ellos, sólo identificando el error tiene poco o nada de valor. La corrección de errores sólo se puede realizar correctamente cuando se conoce la causa principal y ahí es donde la mayoría de las estrategias de pruebas fallan: no tienen en cuenta el ‘hacer fácil el análisis de la causa raíz’. O mejor aún, configuran la estrategia de pruebas de tal forma que el análisis de la causa raíz se vuelve superfluo: ¡una prueba fallida revela no solo un error, sino que también revela intrínsecamente la causa subyacente!

Por tanto, echemos un vistazo al análisis de la causa raíz. ¿Es siempre tan dificil o hay un patrón para la simplicidad del análisis de causa raíz? A ver qué os parece esto: hay pruebas que no necesitan ningún análisis adicional de la causa raíz. La mayoría de las pruebas unitarias (automáticas) son tan específicas que cuando fallan, la causa es clara. Y hay pruebas que son notoriamente difíciles cuando se trata de análisis de causa raíz: pruebas End-to-End. Estas pruebas están en lados opuestos de la Pirámide de prueba.

La Pirámide de prueba como explicaba antes, es una generalización, en la práctica tenemos muchas más capas de integración, como la Pirámide de prueba directamente a la derecha. Si una estrategia de prueba tiene en cuenta la Estrategia de Integración del ciclo de vida de desarrollo y las pruebas se ajustan a las capas de Integración, los errores se relacionan con aspectos de Integración específicos y la causa raíz del error debe estar relacionada con la Integración de las partes subyacentes probadas.

Así que alineemos por completo nuestra estrategia de prueba con el ciclo de vida de desarrollo y eliminemos la necesidad del análisis de causa raíz: ¡ahí cuando las pruebas realmente ponen el valor sobre la mesa!

Este artículo ha sido publicado previamente en SogetiLabs.

Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.