Pregunta de moda estos últimos meses… ¿ATDD? ¿Cómo? ¿Qué? Bien, pues ATDD, que viene de Acceptance Test-Driven Development, también conocido como Storytest Driven Development (STDD), y por otros tantos nombres más, es una práctica en la que todo el equipo, destacando, e incluyendo, a los usuarios y/o al product owner, desarrolladores y tester, analiza conjuntamente los criterios de aceptación, antes de que comience el desarrollo.
Aquí hay dos prácticas claves para estar ante un ATDD, importantes de conocer para diferenciar el ATDD de las tradicionales pruebas de aceptación:
– Antes de implementar (resalto lo de antes de implementar) una necesidad, requisito, historia de usuario, etc., los miembros del equipo (usuarios, o product owners, desarrolladores, tester, etc.) colaboran para crear escenarios, ejemplos, de cómo se comportará dicha necesidad.
– Después, el equipo convierte esos escenarios en pruebas de aceptación automatizadas. Estas pruebas de aceptación típicamente se automatizan usando Selenium o similares, “frameworks” como Cucumber “pegan” las diferentes pruebas, etc. Aquí no me extiendo mucho, para ello tienes la serie de post sobre BDD, especialmente este de la serie: Entendiendo qué es BDD (Behavior-Driven Development) (V). CAPYBARA.
Es decir, que, a diferencia del Test de Aceptación tradicional, el ATDD se diferencia en que las pruebas de aceptación se hacen antes de desarrollar y que se automatizan.
La principal ventaja del ATDD es que ayuda a asegurar que todos los miembros del proyecto entienden qué hay que hacer. Es una técnica grandísima para asegurar de que todos tenemos la misma idea de lo que hay que hacer. E, importante, es una grandísima técnica para asegurar que todos tenemos la misma definición de lo que significa que algo, una necesidad, requisito, historia de usuario, etc., se ha “Terminado”, en terminología ágil el DoD (Definition of Done), recuerda aquello de en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done).
Recuerda también que, aunque ahora se hable mucho más de ello, la mayoría de estas técnicas llevan dando vueltas ya desde hace muchos años, como hablamos en aquel post de “Utilizamos la novedosa técnica de TDD”… ¿Cómo? ¿Novedosa? ¿Seguro?
Dicho todo lo anterior, y en la obligación de no poder acabar el post de otra manera, tengo que decirte que ojo con la automatización de pruebas de aceptación, ojo en el sentido de que no olvides los costes de automatizar y mantener los Test. Sobre este tema de los costes de automatizar, y en el caso concreto del ATDD, hay mucho escrito (véase un ejemplo)… pero nada concluyente. Ojalá pudiera decirte que lo ideal es automatizar un 32,789% de los Test, pero no puedo, sólo toma la recomendación de que automatizar de más conlleva a sobrecostes.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Una pregunta quizá muy básica pero que me gustaría hacerte. Entiendo que las pruebas de aceptación se deben hacer en entorno de producción, ¿no? Al menos es así en las metodologías clásicas. En estas condiciones (un entorno de cliente), ¿es realista pensar en pruebas automatizadas de aceptación?
Gracias por adelantado.
Buenas, como veo que no te respondió en su día, espero te sirva mi aportación aunque a estas alturas,seguro lo tienes ya claro. En cualquier caso empiezo recordándote el nombre de estos test: «Acceptance Test-Driven Development». Esto significa literalmente que el desarrollo está guiado por los test de aceptación y, como bien indica Javier en su post, los escenarios se escriben antes y se automatizan mediante «cucumbers» antes de empezar a picar código, de manera que NO; estos tests no se hacen en pro sino antes ya que sirven para guiar el desarrollo de tu producto. Espero haberte aclarado.