La importancia del ATDD en Agile Testing
El Desarrollo Guiado por Pruebas de Aceptación (#ATDD: Acceptance #Test Drive Development) involucra a ciertos miembros del equipo que poseen diferentes perspectivas y que pertenecen a las áreas de Clientes, Desarrollo y Pruebas, colaborando entre sí para escribir pruebas de aceptación antes de implementar la funcionalidad correspondiente.
Ahora bien, todo esta teoría llevada a la práctica ¿Qué onda? ¿Es practicable en tu entorno de trabajo o aún falta cierta madurez en tu equipo de trabajo y hasta en la organización misma?
Por otra parte, ¿Tu equipo de #testers está lo suficientemente capacitado, entrenado y mentalizado para plantearse frente al resto del equipo completo y proponer un cambio que los haga ir por este camino para -como siempre digo- Ensayar, Inspeccionar y Adaptar? Bien, entonces si te están asaltando toda una serie de preguntas en este mismo momento, te invito a que leas el artículo que escribí donde seguramente podrás encontrar -y ojalá así sea- gran parte de las respuestas que estas buscando que te permitan aclarar tu panorama actual.
Definición
El Desarrollo Guiado por Pruebas de Aceptación (ATDD: Acceptance Test Drive Development) involucra a ciertos miembros del equipo que poseen diferentes perspectivas y que pertenecen a las áreas de Clientes, Desarrollo y Pruebas, colaborando entre sí para escribir pruebas de aceptación antes de implementar la funcionalidad correspondiente.
ATDD también puede denominarse Desarrollo Guiado por Pruebas de Historia (SDD: Story Test Driven Development).
Las conversaciones, debates y discusiones que se generan de manera colaborativa entre dichos miembros ocurren para procurar generar las pruebas de aceptación y a esta situación se la conoce bajo la denominación «los tres amigos», que no es ni más ni menos la representación de las tres perspectivas:
- Cliente ¿Qué problema estamos tratando de resolver?
- Desarrollo (¿Cómo podemos resolver este problema?)
- Prueba (¿Qué pasa si…?)
Entonces basicamente estas pruebas representan el punto de vista del usuario, es decir un requerimiento que ayuda a describir cómo funcionará el producto de software, y servirá como una forma de verificar que el producto de software funcione según lo que se tenga previsto.
Para cierto tipo de proyectos, el equipo se ocupa de automatizar las pruebas de aceptación.
Para la administración de este enfoque de pruebas, se usan herramientas como Fitness o Cucumber ya que permiten la interacción de los miembros del equipo que no son técnicos. Ahora bien, lo importante a mencionar aquí es que al momento de seleccionar una herramienta se piense en que con la misma se deberá promover el objetivo principal del enfoque, es decir la facilitación y conversación entre «los tres amigos» y no que provoque obstáculos que impidan el desarrollo.
El concepto de ATDD lo encontramos en los Programas de Estudios del ISTQB (CTFL y CTAT) y en el Programa de Estudio AiU Certified Tester in AI (CTAI)
En el (ISTQB CTFL 2018)
El término ATDD está mencionado en la sección 1.4.2. Actividades y Tareas de Prueba correspondiente al Análisis de la Prueba.
Tanto el BDD (Desarrollo Guiado por el Comportamiento) como el ATDD (Desarrollo Guiado por Prueba de Aceptación) proponen generar condiciones de prueba y casos de prueba sobre la base de historias de usuario y criterios de aceptación antes de codificar, pudiendo entonces verificar, validar y detectar defectos tanto en las historias de usuario como en los criterios de aceptación.
También está mencionado en la sección 6.1.1. Clasificación de las Herramientas de Prueba correspondiente al Soporte de Herramientas para el Diseño e Implementación de Pruebas.
Las herramientas para diseñar pruebas nos ayudan a crear productos de trabajo que se pueden ir manteniendo durante el diseño e implementación de pruebas, como son los casos de prueba, procedimiento de prueba y datos de prueba. Un ejemplo de este tipo de herramientas lo tenemos con Herramientas de desarrollo guiado por prueba de aceptación y desarrollo guiado por el comportamiento, como Cucumber.
Beneficios esperados
Así como TDD da como resultado aplicaciones diseñadas para ser más fáciles de probar unitarias, ATDD favorece la creación de interfaces específicas para pruebas funcionales. (La prueba a través de la interfaz de usuario real de una aplicación se considera menos efectiva).
En el (ISTQB CTFL-AT)
En la sección 3.1. Métodos de Prueba Ágil correspondiente al 3.1.1. Desarrollo Guiado por Pruebas de Aceptación tenemos la primera mención de ATDD.
El ATDD es una de las tres técnicas (TDD y BDD son las otras) que se usan en equipos ágiles para realizar las pruebas en diferentes niveles de prueba. ATDD como las otras dos representan un claro ejemplo de uno de los principios fundamentales de las pruebas, el beneficio que obtenemos al efectuar pruebas tempranas con actividades de control de calidad como definir pruebas antes de escribir el código.
El ATDD propone dos acciones concretas: definir (a) criterios de aceptación y (b) pruebas durante la creación de las historias de usuario.
Algo importante a mencionar es que es este enfoque es bien colaborativo ya que permite a todas las personas involucradas en el desarrollo del producto de software, entender {cómo} será el comportamiento del componente de software y {qué} necesitarán tanto el desarrollador, como el tester y el responsable del negocio para garantizar ese comportamiento.
Con el ATDD se van creando pruebas reutilizables para las pruebas de regresión con la posibilidad de utilizar herramientas que facilitan la creación y ejecución de los casos de prueba dentro de un proceso de integración continua, ya que dichas herramientas se pueden conectar a las capas de datos y servicios del producto de software que se esté desarrollando, permitiendo ejecutar pruebas a nivel de sistema o aceptación. A través de este esquema de desarrollo, se pueden resolver rápidamente defectos y validar el comportamiento de las prestaciones, ayudando a verificar que se estén cumpliendo los criterios de aceptación de la historia de usuario analizada.
En la sección 3.3.2. Aplicación del Desarrollo Guiado por Pruebas de Aceptacion se amplía aún más el tema.
En el ATDD:
- se priorizan las pruebas.
- se crean los casos de prueba antes de implementar las historias de usuario.
- los casos de prueba son creados por el equipo ágil («tres amigos»).
- los casos de prueba pueden ser manuales o automatizados.
- el «primer momento» es organizar y coordinar un espacio de «taller de especificación» donde «los tres amigos» analizan, discuten y escriben la historia de usuario. Aquí es donde se puede generar un espacio muy provechoso y productivo para todos porque se puede lograr el real entendimiento de todo y entre todos.
- el «segundo momento» es la creación de los casos de prueba por parte del equipo completo guiado por el tester o bien por el tester de manera individual. En mi opinión, recomiendo que se haga de manera conjunta, siempre será mucho mejor esa opción porque además permite la integración entre las partes, y conocerse más allá de los aspectos netamente técnicos.
El enfoque debería darse de manera incremental:
- partiendo de los ejemplos más básicos con preguntas abiertas para llegar a los escenarios más complejos.
- diseñando pruebas positivas con las que se puedan confirmar el correcto comportamiento del producto de software sin establecer condiciones de excepción o error. (¿Happy path?)
- diseñando y ejecutando el equipo completo (en mi recomendación) luego de haber confirmado la serie de casos de prueba positivos, los casos de prueba pero ahora negativos y así cubrir condiciones de excepción, de error y no funcionales como por ejemplo el rendimiento del producto de software bajo cierto tipo de circunstancias, su usabilidad con todo lo que ello conlleva.
- escribiendo tanto para los casos positivos como para los negativos, de una manera en que cualquiera de «los tres amigos» los entienda, con frases en lenguaje natural es decir que no sea técnico, que incluyan las precondiciones necesarias que permitan fijar el entorno adecuado para su ejecución y comprobación de resultados, y por supuesto, considerar tantas las entradas como las salidas relacionadas.
- planteando ejemplos por parte de cualquiera de «los tres amigos» que cubran todas las características de la historia de usuario con la condición de no agregarla a la historia de usuario.
- asegurándose que no haya ejemplos planteados de la historia de usuario que no estén documentados en la misma.
- asegurándose que no haya dos ejemplos que describan las mismas características de la historia de usuario.
En el (CTAI)
En la sección 6.2. Estrategia de la prueba / 6.2.1. Estrategia de prueba para probar aplicaciones de AI (Artificial Intelligence).
Cualquier aplicación que se base en AI puede estar empleando uno o más componentes de AI y no AI, por lo tanto la estrategia de prueba para dicha aplicación debe estar incluyendo los tipos de prueba que todos conocemos, así como otras prácticas que permiten entender nuevos factores específicos para los componentes de AI y su integración con otros componentes de la aplicación. Uno de estos tipos de prueba que se deberán considerar son las pruebas de aceptación.
Espero que te sirva el contenido de este artículo para tus proyectos o tus estudios, y me ayudarías mucho verdaderamente si lo compartes con tus amigos y además dejas un comentario y un like ya que esta red ‘premia’ estas acciones (las de dejar comentarios y compartir por sobre todas las cosas) posicionando el artículo antes que otros, De esta manera aumentará la posibilidad de que otros #testers puedan reaccionar al artículo y conocer sus opiniones a partir de los comentarios que hayan dejado.
Muchas gracias por seguirme.
Puedes también en LinkedIn.
