No tengo ningún documento de investigación o estadística que darle, pero relataré mi experiencia de trabajar en un equipo / organización que históricamente tuvo una cobertura de prueba unitaria de baja a media y sin pruebas de punta a punta, y gradualmente moviendo la barra a donde estamos ahora, con un enfoque más de ATDD (pero, irónicamente, no TDD tradicional).
Específicamente, así es como se desarrollaban los cronogramas del proyecto (y aún se juegan en otros equipos / productos en la misma organización):
- Hasta 4 semanas de análisis e implementación.
- 2 semanas de pruebas de regresión, corrección de errores, estabilización y preparación de lanzamiento
- 1-2 semanas de reparación de defectos conocidos
- 2-3 semanas de limpieza de código y problemas / soporte de posproducción (defectos desconocidos / interrupciones no planificadas)
Esto parece una sobrecarga ridícula , pero en realidad es muy común, a menudo está enmascarado en muchas organizaciones por falta de control de calidad o ineficaz. Tenemos buenos evaluadores y una cultura de pruebas intensivas, por lo que estos problemas se detectan temprano y se solucionan por adelantado (la mayoría de las veces), en lugar de permitir que se desarrollen lentamente en el transcurso de muchos meses / años. La sobrecarga de mantenimiento del 55-65% es inferior a la norma comúnmente aceptada del 80% del tiempo dedicado a la depuración, lo cual parece razonable, porque teníamos algunas pruebas unitarias y equipos multifuncionales (incluido el control de calidad).
Durante el primer lanzamiento de nuestro equipo de nuestro último producto, habíamos comenzado a actualizar las pruebas de aceptación, pero no estaban a la altura del tabaco y todavía teníamos que confiar en muchas pruebas manuales. El lanzamiento fue algo menos doloroso que otros, IMO en parte debido a nuestras pruebas de aceptación al azar y también en parte debido a nuestra muy alta cobertura de pruebas unitarias en relación con otros proyectos. Aún así, pasamos casi 2 semanas en regresión / estabilización y 2 semanas en problemas de posproducción.
Por el contrario, cada lanzamiento desde ese lanzamiento inicial ha tenido criterios de aceptación temprana y pruebas de aceptación, y nuestras iteraciones actuales se ven así:
- 8 días de análisis e implementación
- 2 días de estabilización
- 0-2 días combinados de soporte de postproducción y limpieza
En otras palabras, progresamos de 55-65% de gastos generales de mantenimiento a 20-30% de gastos generales de mantenimiento. El mismo equipo, el mismo producto, la principal diferencia es la mejora progresiva y la racionalización de nuestras pruebas de aceptación.
El costo de mantenerlos es, por sprint, 3-5 días para un analista de control de calidad y 1-2 días para un desarrollador. Nuestro equipo tiene 4 desarrolladores y 2 analistas de control de calidad, por lo que (sin contar UX, gestión de proyectos, etc.) eso es un máximo de 7 días hábiles de 60, que redondearé a una sobrecarga de implementación del 15% solo para estar en El lado seguro.
Dedicamos el 15% de cada período de lanzamiento a desarrollar pruebas de aceptación automatizadas, y en el proceso podemos reducir el 70% de cada lanzamiento haciendo pruebas de regresión y reparando errores de preproducción y posproducción.
Es posible que haya notado que la segunda línea de tiempo es mucho más precisa y también mucho más corta que la primera. Eso es posible gracias a los criterios de aceptación y las pruebas de aceptación iniciales, ya que simplifica enormemente la "definición de hecho" y nos permite tener mucha más confianza en la estabilidad de una versión. Ningún otro equipo (hasta ahora) ha tenido éxito con un cronograma de lanzamiento quincenal, excepto tal vez cuando se realizan lanzamientos de mantenimiento bastante triviales (solo corrección de errores, etc.).
Otro efecto secundario interesante es que hemos podido adaptar nuestro calendario de lanzamientos a las necesidades comerciales. Una vez, tuvimos que alargarlo a aproximadamente 3 semanas para que coincidiera con otra versión, y pudimos hacerlo mientras brindamos más funcionalidad pero sin gastar tiempo adicional en pruebas o estabilización. En otra ocasión, tuvimos que acortarlo a aproximadamente 1½ semanas, debido a días festivos y conflictos de recursos; tuvimos que asumir menos trabajo de desarrollo, pero, como era de esperar, pudimos dedicar correspondientemente menos tiempo a las pruebas y la estabilización sin introducir ningún defecto nuevo.
Entonces, en mi experiencia, las pruebas de aceptación, especialmente cuando se realizan muy temprano en un proyecto o sprint, y cuando se mantienen bien con los criterios de aceptación escritos por el Propietario del producto, son una de las mejores inversiones que puede hacer. A diferencia del TDD tradicional, que otras personas señalan correctamente se centra más en la creación de código comprobable que en el código libre de defectos : ATDD realmente ayuda a detectar defectos mucho más rápido; es el equivalente organizacional de tener un ejército de probadores haciendo una prueba de regresión completa todos los días, pero mucho más barata.
¿ATDD lo ayudará en proyectos a más largo plazo realizados en RUP o (ugh) estilo Cascada, proyectos que duran 3 meses o más? Creo que el jurado todavía está en eso. En mi experiencia, los riesgos más grandes y más feos en proyectos de larga duración son plazos poco realistas y requisitos cambiantes. Los plazos poco realistas harán que las personas tomen atajos, incluidos los atajos de prueba, y los cambios significativos en los requisitos probablemente invaliden una gran cantidad de pruebas, lo que requerirá que se reescriban y posiblemente inflen la sobrecarga de la implementación.
Estoy bastante seguro de que ATDD tiene una recompensa fantástica para los modelos Agile, o para los equipos que no son oficialmente Agile pero tienen calendarios de lanzamiento muy frecuentes. Nunca lo he probado en un proyecto a largo plazo, principalmente porque nunca he estado o incluso he oído hablar de una organización dispuesta a intentarlo en ese tipo de proyecto, así que inserte aquí el descargo de responsabilidad estándar. YMMV y todo eso.
PD En nuestro caso, no se requiere un esfuerzo adicional del "cliente", pero tenemos un propietario de producto dedicado y a tiempo completo que realmente escribe los criterios de aceptación. Si está en el negocio de "consultoría", sospecho que podría ser mucho más difícil lograr que los usuarios finales escriban criterios de aceptación útiles. Un propietario de producto / gerente de producto parece un elemento bastante esencial para hacer ATDD y, aunque una vez más solo puedo hablar desde mi propia experiencia, nunca he oído hablar de ATDD que se practique con éxito sin alguien para cumplir ese papel.
