Desarrollo Dirigido por Tests de Aceptación (ATDD)

Resultado de imagen de client team

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:

Están escritas con el vocabulario del negocio del cliente, no vocabulario técnico.

Tests de Aceptación

Resultado de imagen de test

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. 

Cuantas menos palabras para decir lo mismo, mejor:

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?

Resultado de imagen de machine intelligence

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

Resultado de imagen de test aceptacion

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

Resultado de imagen de estimacion

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:

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

Resultado de imagen de psicologo

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:

 

Ejemplos que pueden salir de la anterior descripción:

 

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