En Extreme Programming (XP), la calidad no es una fase final ni la responsabilidad de un equipo separado de "QA" (Quality Assurance). La calidad se construye de forma continua e integral a lo largo de todo el proceso de desarrollo. La estrategia de XP se basa en múltiples capas de pruebas que proporcionan una retroalimentación rápida y constante, asegurando que el software no solo funcione, sino que esté bien diseñado y cumpla con las expectativas del cliente.
17.1. Pruebas unitarias automáticas
Las pruebas unitarias son la base de la pirámide de calidad en XP. Son pruebas de bajo nivel, escritas por los propios desarrolladores, que verifican el comportamiento de una pequeña pieza de código (una "unidad"), como una función o un método de una clase, de forma aislada.
La práctica que garantiza su existencia y exhaustividad es el Desarrollo Guiado por Pruebas (TDD). En XP, no se escribe una línea de código de producción a menos que haya una prueba unitaria que falle y que la necesite. Este enfoque asegura:
- Cobertura completa: Prácticamente todo el código de producción está cubierto por pruebas unitarias desde su nacimiento.
- Red de seguridad para la refactorización: Este conjunto masivo de pruebas se ejecuta en segundos o minutos. Proporciona a los desarrolladores la confianza para refactorizar y mejorar el código constantemente, sabiendo que si rompen algo, las pruebas se lo notificarán de inmediato.
- Documentación viva: Las pruebas unitarias actúan como ejemplos ejecutables de cómo usar el código. Un desarrollador puede leer las pruebas de un componente para entender su comportamiento y su API.
Estas pruebas se integran en el sistema de Integración Continua (CI), ejecutándose automáticamente cada vez que se sube un cambio al repositorio, lo que garantiza que la base de código se mantenga siempre saludable.
17.2. Pruebas de aceptación del cliente
Si las pruebas unitarias verifican que el código hace las cosas bien (lógica interna correcta), las pruebas de aceptación verifican que el código hace las cosas correctas (cumplir con los requisitos del negocio). Estas son pruebas de más alto nivel que validan una historia de usuario o una funcionalidad completa desde la perspectiva del cliente.
Características de las pruebas de aceptación en XP:
- Definidas por el cliente: El cliente (o su representante) es responsable de especificar los criterios de aceptación para cada historia de usuario. Lo hace en colaboración con los desarrolladores y testers para asegurar que sean claras y probables.
- Enfocadas en el comportamiento: No se preocupan por los detalles de implementación, sino por el comportamiento observable del sistema. Por ejemplo: "Cuando un usuario con una suscripción premium inicia sesión, debe ver el botón de 'Descargar en HD'".
- Automatización: Siempre que sea posible, estas pruebas también se automatizan. Herramientas como Selenium, Cypress o frameworks de BDD (Behavior-Driven Development) como Cucumber permiten escribir estas pruebas en un lenguaje cercano al natural, que luego se ejecuta contra la aplicación.
- Criterio de finalización: Una historia de usuario no se considera "terminada" hasta que todas sus pruebas de aceptación pasan. Esto crea una definición de "Hecho" (Definition of Done) clara y objetiva.
17.3. Cobertura de pruebas y métricas de calidad
Si bien XP no se obsesiona con las métricas por sí mismas, estas pueden ser herramientas útiles para evaluar la salud del proyecto y guiar las mejoras.
- Cobertura de pruebas (Test Coverage): Esta métrica indica qué porcentaje del código de producción es ejecutado por las pruebas automáticas. Gracias a TDD, los equipos de XP a menudo alcanzan niveles de cobertura muy altos (90% o más) de forma natural. Sin embargo, el equipo es consciente de que la cobertura es una medida cuantitativa, no cualitativa.
- El 100% de cobertura no garantiza la ausencia de errores. Una prueba puede "cubrir" una línea de código sin verificar realmente su comportamiento de forma significativa.
- Es más importante la calidad de las aserciones (los `asserts` o `expects` de las pruebas) que el simple porcentaje de cobertura.
- Otras métricas de calidad: Además de la cobertura, los equipos pueden monitorear:
- Tasa de éxito de la construcción (Build Success Rate): Un alto porcentaje de construcciones exitosas en el servidor de CI indica un código base estable.
- Complejidad ciclomática: Herramientas de análisis estático pueden medir la complejidad del código. Un aumento en la complejidad puede señalar la necesidad de refactorización.
- Número de bugs reportados: Un seguimiento del número de errores que escapan del proceso de desarrollo y son reportados por el cliente puede ayudar a identificar debilidades en la estrategia de pruebas.
En XP, estas métricas no se usan para evaluar a individuos, sino para facilitar una conversación dentro del equipo sobre la calidad y cómo mejorarla. La meta final es siempre la misma: entregar software funcional y de alta calidad que deleite al cliente.