Vamos a un tema controversial. Hay varios informes dando vueltas sobre el éxito de escribir los requerimientos y automatizarlos a través de pruebas de aceptación (a veces llamado Requerimientos Guiado por Pruebas, Desarrollo Guiado por Historias, y -dependiendo de a quién le pregunten- Desarrollo Guiado por Comportamiento o BDD). Sin embargo en la práctica sólo una muy pequeña parte de la comunidad utiliza esta técnica. Y ya hay varios líderes conocidos que salieron a decir que las pruebas de aceptación son una mala idea y un desperdicio de esfuerzo.
Las pruebas de aceptación que se escriben al inicio de cada iteración, ¿son una buena idea en la teoría que se convertió en una práctica inefectiva por la falta de adopción?
Primero definamos a qué nos referimos con prueba de aceptación automatizada: son pruebas que se escriben al inicio de la iteración, y representan una forma ejecutable de los requerimientos. Son ejemplos detalladas de cómo se supone que funcione el sistema cuando el requerimiento al que describe se complete - son una respuesta a la pregunta "¿cómo debería funciona cuando haya terminado?". Históricamente, FIT y FITNesse fueron las herramientas más utilizadas este fin, aunque hoy hay otras más como cucumber y rspec.
La realidad es que este tipo de pruebas no está teniendo mucho éxito. De hecho, James Shore recientemente escribió en su Twitter lo que él considera son las 3 falencias principales de FIT y FITNesse:
- Falla de Fit #1: el mantenimiento. El HTML es dificil de mantener y hacer refactor.
- Falla de Fit #2: los clientes. Los clientes no generan los documentos, y esa era toda la idea de fondo.
- Falla de Fit #3: los programadores. Fit está pensando para el modelo de dominio y el Valor. A la mayoría de los programadores no les interesa. Hay un impedimento de intereses.
Por otro lado, Brian Marick dio su punto de vista en una entrevista de InfoQ:
"Lo interesante que noté es que las pruebas de aceptación ni de lejos funcionan tan bien como el Diseño Guiado por las Pruebas: cuando se diseña una prueba, a menudo se obtiene mucho feedback y comprensión que hace notar su valor. Y por supuesto que las pruebas unitarias hacen lo mismo. A la fecha, no parece que las pruebas de aceptación lleven a consecuencias estructurales profundas, como lo hace el refactor para las pruebas unitarias. Entonces la pregunta que me hago es: si el valor viene de escribir la prueba, y hay un costo sustancial en escribir todo el código de prueba, ¿estamos recuperando esa inversión al automatizar este tipo de pruebas? Porque si no recuperamos la inversión, entonces mejor escribamos las pruebas en un pizarrón, hagamos que los desarrolladores las vayan implementando de a una, comprobando manualmente e incluso mostrándolo al Dueño del Producto, y cuando terminemos, simplemente borremos el pizarrón y sigamos adelante. ¿Por qué esa necesidad de guardar estas pruebas para correrlas una y otra y otra vez?"
Por supuesto, también hay muchos otros líderes en la comunidad que recomiendan utilizar pruebas de aceptación automatizadas; entre ellos tenemos a nombres como Robert C. Martin, Joshua kerievsky, y el mismo James Shore.
Chris Matts ofrece una interesante mirada alternativa a la situación, como un problema de llegada de información. Supongamos que tenemos un proceso de desarrollo de software (no necesariamente Ágil) que no tiene pruebas de aceptación escritas de antemano. El equipo de QA usualmente ejecuta sus propios escenarios de prueba y cuando encuentra defectos los informa a los desarrolladores. Estos defectos se encuentran de manera aleatoria y por lo tanto afectan la velocidad del equipo de software, porque utilizan un porcentaje de su capacidad para resolver estos defectos. La información nueva llega de manera aleatoria al equipo de desarrollo.
Ahora, consideremos qué pasaría si las pruebas fueran escritas por QA antes de que se inicie el desarrollo. La información brindada por estos escenarios ahora ocurre al inicio de la iteración de manera predecible. Por lo tanto se reduce la incertidumbre, la velocidad se vuelve más estable (menos interrupciones aleatorias), y esto significa más predecibilidad.
Entonces, ¿las pruebas de aceptación son sólo para los pocos afortunados que las hicieron funcionar? ¿Existe algún factor común que provoca que no tengan una adopción general? ¿O simplemente es dificil de probar su valor, y todos los equipos de desarrollo deberían aspirar a adoptar esta práctica?
