Testing en metodologías ágiles

Un buena metodología de tests es una parte indispensable de una metodología ágil. En el mundo ágil, hacer test no es una fase separada; es básicamente uno de los diferentes aspectos del desarrollo de software. Se debe aplicar de forma constante dentro del propio esfuerzo del equipo de trabajo.

El testing agil

El testing en metodologías más tradicionales es una fase separada del proyecto, que se realiza después de terminar con el desarrollo. Sin embargo en las metodologías ágiles se debe incorporar el testing desde el inicio del proyecto. Se debe trabajar con testing ágil, mano a mano con el equipo de desarrollo; y aportando feedback constante durante todo el proceso de desarrollo.

También se tiende a avandonar la idea de un departamento de calidad de software (QA) como un elemento separado dentro de los proyectos. En las metodologías ágiles, los testers son parte del equipo de desarrollo. En muchos casos, se vá más allá; y ni siquiera existe una figura dedicada exclusivamente a realizar los test. Los testers de los equipos ágiles colaboran con los desarrolladores, y los ayudan a diseñar tests; pero todos los miembros del equipo de desarrollo son responsables de testear constantemente el código.

Podemos resumir los principios del test en entornos ágiles con los siguientes puntos:

• El testing no es una fase, es parte integral del desarrollo del proyecto.
• El testing en una herramienta para facilitar el avance del proyecto. Tener test aumenta la confianza en el código, y reduce las preocupaciones con los efectos laterales, o al refactorizar
• Todo el equipo realiza pruebas. Si consideramos que en un equipo ágil todos son responsables del avance del proyecto, es lógico que todos sean responsables de las pruebas.
• El testing constante reduce el tiempo de feedback, y hace que sea más fácil detectar de mánera temprana problemas de concepto o de diseño.
• El código se mantiene mucho más limio. Al tener que pasar pruebas constantemente, existe menos margen para dejar arreglos temporales que ya se corregiran más adelante.
• Mayor automatización de las pruebas. Ya que el equipo tiene que ejecutar las pruebas de forma constante, se tienden a avandonar grandes pruebas basadas en documentos formales, y se dispone de pruebas automáticas que son fáciles de repetir, y que tienen mayor factor de confianza.

La piramide del testing de Mike Cohn es una imágen muy esclarecedora de las diferencias entre el test en el desarrollo de software tradicional, y el test en el desarrollo de software ágil:

Se ve claramente que en el desarrollo tradicional existe un gran esfuerzo en pruebas manuales y funcionales; mientras que en el desarrollo ágil la mayor parte de las pruebas son automáticas. Esto se traduce rápidamente en una reducción de costes:

• Solucionar un defecto durante el desarrollo es mucho más sencillo que solucionar una incidencia en el producto terminado. Hay muchas menos dependencias que se puedan ver afectadas, y el desarrollo funcionale está fresco
• Ejecutar un test unitario es muchísimo más rápido que ejecutar un test desde la interfaz de usuario. Si tenemos código de calidad (SOLID y Clean Code), podremos mockear los servicios necesarios y validar las funcionalidades "por su cuenta" en unos segundos; sin tener que levantar un entorno completo y navegar por las interfaces hasta llegar al lugar donde validar dichas funcionalidades de forma completamente integrada.
• Los test unitarios permiten aislar de forma rápida los defectos, y hace mucho más rápido localizar y solucionar las partes problemáticas. Si como dijimos antes, los test son unitarios, y los servicios están mockedos; cuando tenemos un error durante integración, resulta más evidente la búsqueda de los problemas en las partes de transferencia de datos, y confiar en las funciones probadas.