Estrategia de pruebas en un entorno ágil

Definición

Probar significa ejecutar el programa con la intención de encontrar anomalías o fallos.

G. Myers (The Art of Software testing)

La prueba es la ejecución o evaluación de un sistema o componente mediante métodos automáticos o manuales, para verificar que cumple sus especificaciones o identificar las diferencias entre los resultados esperados y los resultados obtenidos.

Standard Glossary of Software Engineering Terminology

El error es humano y nuestro mundo material está sujeto al desgaste, por lo que no podemos escapar al error, ya que todo sistema que envejece acaba por fallar. Cuando se produce un error, ya sea humano o material, el estado del sistema en error se vuelve inválido, y observamos entonces un fallo, una anomalía en el sistema; existe entonces una diferencia entre el comportamiento esperado y el comportamiento observado, y todo sistema defectuoso inducirá inevitablemente un fallo, consecuencia del error. Según la gravedad del error inicial, el fallo del sistema será más o menos grave. Hay sistemas en los que el más mínimo error es inaceptable, bien porque están en juego vidas humanas, bien porque la pérdida financiera no es admisible.

Tomemos como ejemplo el proyecto SpaceX. Tras un exitoso despegue en Texas y una exitosa operación de separación, las dos etapas del cohete Starship finalmente explotaron el 18 de noviembre...

Los distintos tipos de pruebas

La agilidad no ha revolucionado realmente la estrategia de pruebas. Las pruebas son ahora, como lo eran entonces, el proceso de verificación y validación de la calidad del software. Si quiere un producto de calidad tiene que probarlo antes de entregarlo.

Lo que realmente ha cambiado con los métodos ágiles es que se prueba más temprano y mucho más que antes, y esto se debe al mecanismo de los sprints. Si al final de un sprint tenemos que entregar una pieza de producto funcional, esta pieza de producto debe entregarse con toda la calidad requerida. En otras palabras, se han realizado necesariamente las pruebas necesarias durante el sprint.

La agilidad nos ha enseñado a desglosar los requisitos en User Story (US). Así, por ejemplo, de una especificación de 200 páginas para una solución a entregar en el pasado, ahora hemos pasado, en modo ágil, a cientos y cientos de US a entregar para esta misma solución. Digamos que para cada sprint, estamos obligados a desarrollar 15 US, para cada una de estas 15 US que desarrollaremos durante un sprint, se deben prever las pruebas necesarias para garantizar la calidad de la entrega. En modo ágil, entregamos poco a poco, probando sistemáticamente a medida que avanzamos, mientras que en el pasado, podíamos desarrollar nuestro código y ocuparnos de probarlo más tarde, mucho más tarde.

Ahora hay un problema que no es nuevo: durante un sprint no se puede probar todo. Incluso en el pasado, en el ciclo en V por ejemplo, no se podía probar todo a la vez.

En un ciclo en V, las distintas etapas del ciclo de desarrollo se llevan a cabo de forma secuencial, desde el análisis de requisitos hasta las pruebas de aceptación, que es la etapa final de validación de toda la solución encargada.

En este método de desarrollo tradicional, como muestra el diagrama anterior, la secuencia de acontecimientos es la siguiente: Necesidades (análisis de requisitos) - Diseño (especificaciones y conceptos) - Implementación (codificación) - Verificación (las distintas pruebas) - Aceptación - Mantenimiento (post-proyecto). De hecho, cada fase previa a la programación está asociada a un nivel de pruebas.

Una vez terminado el desarrollo, los desarrolladores escribían las pruebas unitarias...

¿Qué tiene que decir la agilidad sobre las pruebas?

Las actividades de prueba deben comenzar lo antes posible en el ciclo de desarrollo del software y centrarse en objetivos definidos.

Hemos visto que, en el ciclo en V, las pruebas se realizan secuencialmente en diferentes contextos. En la agilidad, en un sprint, tiene que hacer todas las pruebas que pueda, ya sean de caja negra o de caja blanca. En la agilidad, lo que realmente va a cambiar es que vamos a compactar todas las pruebas posibles en un sprint. Pero como nuestra solución se entrega de manera progresiva no vamos a probarlo todo en un sprint. Si, por ejemplo, en un proyecto de red ferroviaria, aún no hemos creado las clases de negocio que hablan de la señalización, es imposible probar si un tren que circula por una vía respeta realmente la señalización. En cambio, como a nuestro nivel de desarrollo sabemos hacer circular un tren por varias vías en nuestro simulador, ya habremos realizado todas las pruebas posibles relativas a la circulación del tren por las vías. Por ejemplo, ¿el tren sigue la vía correcta cuando cambiamos la aguja? ¿El tren descarrila cuando toma una curva a una velocidad excesiva? No debemos esperar a que todo el sistema esté desarrollado para comenzar a realizar estas pruebas. Avanzamos sprint a sprint, pero con toda la calidad necesaria. Podemos deducir que la calidad de las pruebas de caja...