Diseño ágil con TDD

3.3. ¿Está hecho o no?

Otra ventaja de dirigir el desarrollo por las historias y, a su vez, por los ejemplos, es que vamos a poder comprobar muy rápido si el programa está cumpliendo los objetivos o no. Conocemos en qué punto estamos y cómo vamos progresando. El Dueño de Producto puede revisar los tests de aceptación y ver cuántos se están cumpliendo, así que nuestro trabajo gana una confianza tremenda. Es una gran manera de fomentar una estrecha colaboración entre todos los roles el equipo.

Piénselo bien: ¡la propia máquina es capaz de decirnos si el programa cumple las especificaciones el cliente o no! De cara a hacer modificaciones en nuevas versiones del programa y lanzarlo a producción, el tiempo que tardamos en efectuar las pruebas de regresión disminuye de manera drástica, lo cual se traduce en un ahorro considerable.

Nota Los tests de regresión deben su nombre al momento en que se ejecutan, no a su formato ni a otras características. Antes de lanzar una nueva versión de un producto en producción, ejecutamos todas las pruebas posibles, tanto manuales como automáticas para corroborar que tanto las nuevas funciones como las existentes funcionan.

Regresión viene de regresar, puesto que regresamos a funcionalidad desarrollada en la versión anterior para validar que no se ha roto nada. Cuando no se dispone de una completa batería de tests, la regresión completa de una aplicación puede llevar varios días en los que el equipo de calidad ejecuta cada parte de la aplicación con todas y cada una de sus posibles variantes. Hablando en plata; una tortura y un gasto económico importante.


Copyright (c) 2010-2013 Carlos Ble. La copia y redistribución de esta página se permite bajo los términos de la licencia Creative Commons Atribución SinDerivadas 3.0 Unported siempre que se conserve esta nota de copyright.