El Desarrollo Dirigido por Test de Aceptación(ATDD) o también llamados Story Test-Driven Development (STDD), son el criterio escrito de que el software cumple los requisitos de negocio que el cliente demanda. Son ejemplos escritos por el dueño del producto.
El trabajo del analista de negocio será reemplazar multitud de paginas de requisitos escritos en lenguaje natural (nuestro idioma), por ejemplos ejecutables surgidos por el consenso entre los distintos miembros del equipo, incluyendo el cliente.
El algoritmo es similar al del TDD de tres pasos.
En ATDD la lista de ejemplos (tests) de cada historia, se escribe en una reunión que incluye:
- Dueños de producto
- Desarrolladores
- Responsables de Calidad
Todo el equipo debe entender qué es lo que hay que hacer y por qué.
«Si no somos capaces de entendernos con el cliente, ni la mejor técnica de desarrollo de todos los tiempos producirá un buen resultado»
Historias de Usuario
Enunciado
El enunciado de una historia es una frase corta (alrededor de 5 palabras) en lenguaje humano, que resume qué es lo que hay que hacer.
Ejemplos de enunciados de historias de usuario:
- Formulario de inscripción - Login en el sistema - Reservar una habitación - Añadir un libro al carrito de la compra - Pago con tarjeta de crédito - Anotar un día festivo en el calendario - Informe de los artículos más vendidos - Darse de baja en el foro - Buscar casas de alquiler en Tenerife
Están escritas con el vocabulario del negocio del cliente, no vocabulario técnico.
Tests de Aceptación
Cada historia de usuario provoca una serie de preguntas acerca de los múltiples contextos en que se pueda dar.
Cada historia de usuario contiene una lista de ejemplos que cuentan lo que el cliente quiere, con total claridad y ninguna ambigüedad. Escribir una definición formal incurre en el peligro de la imprecisión y la malinterpretación, mientras que contarlo con ejemplos ilustrativos, transmite la idea sin complicaciones.
La respuestas a estas preguntas son afirmaciones o ejemplos, escritos en lenguaje humano, los cuales transformamos en test de aceptación que tanto el cliente, como los desarrolladores, como la máquina, entienden.
- Cuando el libro X se añade al carrito, el sistema devuelve un mensaje que dice: “El libro X ha sido añadido al carrito” - Al mostrar el contenido del carrito aparece el libro X - El libro X ya no aparece entre los libros a añadir al carrito
Cuantas menos palabras para decir lo mismo, mejor:
- Añadir libro X en stock produce: “El libro X ha sido añadido al carrito” - Libro X está contenido en el carrito - Libro X ya no está en catálogo de libros
Las preguntas surgidas de una historia de usuario pueden incluso dar lugar a otras historias que pasan a engrosar el backlog o lista de requisitos: “Si el libro no está en stock, se enviará un email al usuario cuando llegue”.
¿Cómo puede entender todo esto la máquina?
Mágicamente no. El equipo de desarrollo tiene que hacer el esfuerzo de conectar esas frases con los puntos de entrada y salida del código. Para esto existen diversos frameworks libres y gratuitos que reducen el trabajo, como por ejemplo Cucumber.
Flow de Trabajo
Para cada test de aceptación de una historia de usuario, habrá un conjunto de tests unitarios y de integración de grano más fino que se encargará, primero, de ayudar a diseñar el software y, segundo, de afirmar que funciona como sus creadores querían que funcionase.
No empezamos el diseño en torno a una supuesta interfaz gráfica de usuario ni con el diseño de unas tablas de base de datos, sino marcando unos criterios de aceptación que nos ayuden a ir desde el lado del negocio hasta el lado más técnico pero siempre concentrados en lo que el cliente demanda, ni más ni menos.
Es más fácil hacer modificaciones cuando se ha diseñado así, de arriba a abajo, en vez de abajo a arriba.
Estimación
Por si misma, una historia aislada es difícil de estimar incluso con este formato. A base de iterar, estimar en cada iteración y hacer retrospectiva al final de la misma, iremos refinando la habilidad de escribir historias y estimarlas.
Qué y no Cómo
Una de las claves de ATDD es justamente que nos permite centrarnos en el qué y no en el cómo. Debemos preguntar al cliente qué quiere y no cómo lo quiere. Evitamos a toda costa ejemplos que se meten en el cómo hacer, más allá del qué hacer.
Ejemplos que NO debemos seguir ya que se meten en cómo hacer:
- Al rellenar el cuadro de texto de buscar y pulsar el botón contiguo, los resultados aparecen en la tabla de la derecha - Al introducir la fecha y hacer click en el botón de añadir, se crea un nuevo registro vacío - Los libros se almacenan en la tabla Libro con campos: id, titulo y autor - Seleccionar la opción de borrar del combo, marcar con un tick las líneas a borrar y verificar que se eliminan de la tabla al pulsar el botón aplicar. - Aplicación Flash con destornilladores y tornillos girando en 3D para vender artículos de mi ferretería por Internet
Cuando partimos de especificaciones como estas corremos el riesgo de pasar por alto el verdadero propósito de la aplicación, la información con auténtico valor para el negocio del cliente.
Reuniones con el Cliente
Con ATDD nos convertimos un poco en psicólogos en lugar de pretender ser adivinos. A base de colaboración encontramos y clasificamos la información que más beneficio genera para el usuario.
En las primeras reuniones con el cliente solamente hay que identificar los módulos que tienen valor de negocio, es decir, aquellos conjuntos lógicos que tengan relación con una estrategia de negocio. Por ejemplo, de cara a ofrecer determinados servicios: servicio de venta, de alquiler, de consultoría…
Ejemplo de descripción insuficiente:
- Buscando por Santa Cruz de Tenerife, aparece una lista de pisos en alquiler.
Ejemplos que pueden salir de la anterior descripción:
- Buscando que el precio sea inferior a 600e, e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que no superan los 600e mensuales de alquiler y que se encuentran en la ciudad de Santa Cruz de Tenerife - Buscando que el precio esté entre 500e y 700e y que tenga 2 habitaciones e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que cumplen las tres condiciones - Buscando que tenga 3 habitaciones y 2 cuartos de baño, e introduciendo el texto "Santa Cruz de Tenerife", el sistema muestra una lista de pisos que cumplen las tres condiciones - Buscando con el texto "Tenerife", el sistema muestra la lista de pisos de toda la provincia de Santa Cruz de Tenerife - En la lista, cada piso se muestra mediante una fotografía y el número de habitaciones que tiene
Una vez los clientes ven estos ejemplos, ellos mismos descubren dudas sobre lo que necesitan para su negocio.
Ellos mismos nos dirán ¿hay que pensar todas estas cosas?
Entonces le comentamos que los ordenadores siguen siendo maquinas muy tontas y que si esas decisiones sobre el negocio no las validan ellos, tendremos que decidirlas nosotros, que no somos expertos en su negocio.
A partir de ahí empezaran a involucrarse mas en el desarrollo y todos comenzamos a hablar en el mismo idioma.
Ventajas del uso de ATDD
- No trabajaremos en funciones que finalmente no se van a usar.
- Forjaremos un código que esta listo para cambiar si fuera necesario porque su diseño no está limitado por un diseño de base de datos ni por una interfaz de usuario.
- Se puede 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
Fuente: Diseño Ágil con TDD