Cómo ATDD le guía en la creación colaborativa de aplicaciones centradas en el usuario
Agile 101
Agil Introducción
Agile Metodologias
Agil Practicas
Impulsar la aceptación de usuarios y clientes con ATDD
El panorama de la ingeniería del software está plagado de jerga e inicialismos. Por ejemplo, parece especialmente aficionado a los inicialismos que terminan en D-D. A menudo puede resultar frustrante tratar de mantenerse al día con tantos conceptos. En esta entrada, hablaremos de uno de los muchos inicialismos que terminan en D en el ámbito del software: Desarrollo orientado a las pruebas de aceptación.
El Desarrollo Orientado a Pruebas de Aceptación, o ATDD, es una metodología de desarrollo de software, a menudo asociada a las metodologías ágiles, que fomenta la colaboración entre los desarrolladores, los probadores y las partes interesadas del negocio, y en la que la automatización de las pruebas desempeña un papel importante.
Como su nombre indica, ATDD está relacionado con TDD, o Test-Driven Development. También tiene similitudes con enfoques como SBE (Especificación por ejemplo) y BDD (Desarrollo orientado al comportamiento). A lo largo del artículo, comprenderá las similitudes y diferencias entre estos enfoques.
¿Qué es el Desarrollo Dirigido por Pruebas de Aceptación?
Empecemos diciendo lo que no es ATDD. No es una técnica de pruebas, a pesar de lo que su nombre pueda sugerir. En cambio, el desarrollo basado en pruebas de aceptación es una técnica de programación. Al igual que su «primo» TDD, ATDD pone la automatización de las pruebas en primer plano. Al adoptarlo, los equipos utilizarán casos de prueba automatizados para impulsar el desarrollo del código de producción.
A diferencia del TDD, que suele considerarse una práctica de ingeniería, el ATDD es un esfuerzo de equipo: reúne a diferentes actores del proceso de desarrollo de software -testers, ingenieros, partes interesadas del negocio- para colaborar. El resultado de esta colaboración son los requisitos de la aplicación, expresados en un formato comprensible para todos, que luego se convierten en pruebas de aceptación automatizadas.
¿Cuál es el objetivo principal del desarrollo basado en pruebas de aceptación?
El objetivo de ATDD es fomentar una colaboración que dé lugar a una comprensión compartida de los requisitos del sistema, en forma de especificaciones escritas en un lenguaje sencillo. A continuación, las especificaciones se convierten en casos de pruebas de aceptación automatizadas. ¿Cuál es el beneficio de hacer eso?
Para entender por qué es útil, pensemos primero en las pruebas unitarias. Se trata de una forma de prueba que, por su naturaleza, está muy centrada en el desarrollador. Ayuda a los ingenieros a documentar sus suposiciones sobre su código en formato ejecutable. Las pruebas unitarias resuelven el problema de «¿estamos construyendo la cosa bien?».
Sin embargo, las pruebas unitarias no resuelven el problema de «¿estamos construyendo la cosa correcta?». Para ello, hay que recurrir a las pruebas de aceptación, que verifican el funcionamiento de la aplicación en función de un conjunto de criterios de aceptación descubiertos a través de conversaciones con un experto en la materia.
En pocas palabras, el desarrollo basado en pruebas de aceptación resuelve el problema de que el equipo de desarrollo implemente funciones que no resuelven las necesidades del cliente.
Un componente esencial de ATDD es la automatización: las especificaciones creadas a partir de las conversaciones se convierten en pruebas ejecutables que garantizan que los ingenieros de software implementen las características de acuerdo con los requisitos.
Breve historia
En su libro seminal » Desarrollo dirigido por pruebas: Por ejemplo», publicado por primera vez en el año 2000, Kent Beck menciona brevemente el ATDD -que él llama Application Test-Driven Development-, pero descarta la idea.
Sin embargo, el enfoque comenzó a ganar fuerza de todos modos, probablemente debido al éxito de herramientas como Fit y Fitnesse.
En 2006, Dan North introdujo el concepto de desarrollo impulsado por el comportamiento, que en un principio sólo pretendía sustituir parte del vocabulario de TDD, pero acabó evolucionando hacia el análisis de requisitos. BDD comparte muchas similitudes con ATDD y, con el tiempo, gran parte del vocabulario, las herramientas y los enfoques del primero fueron adoptados por el segundo.
¿Cómo funciona / Principios y prácticas?
Una visión general de la ATDD
El desarrollo dirigido por pruebas de aceptación tiene un flujo de trabajo similar al de TDD, ya que consiste en crear pruebas antes de escribir el código de producción. A diferencia de TDD, que se basa en pruebas unitarias, las pruebas de ATDD son pruebas de aceptación. Las pruebas nacen de las especificaciones que surgen de las discusiones en las que participan los desarrolladores, los probadores y las partes interesadas del negocio o los clientes.
Src: Mysoftwarequality & Gojko Adzic
Tras la creación de las pruebas, los desarrolladores escriben el código para que esas pruebas se superen, implementando las características de acuerdo con las especificaciones.
De este modo, no sólo se obtienen especificaciones completas que todos pueden entender y a las que pueden contribuir -independientemente de las habilidades de codificación-, sino que también se garantiza que los desarrolladores construyan realmente lo que el cliente necesita.
Ciclo de desarrollo basado en pruebas de aceptación
Aunque no hay un acuerdo universal sobre las fases del ciclo de desarrollo basado en pruebas de aceptación, a menudo se ven estos 4 pasos: discutir, destilar, desarrollar y demostrar.
Discutir
Durante la reunión de planificación -común a prácticamente todas las metodologías/marcos bajo el paraguas ágil- los probadores y desarrolladores discutirán las tareas/historias de usuario elegidas para su implementación en la siguiente iteración o sprint con el interesado/propietario del producto/cliente para extraer la mayor cantidad de información posible de ellas.
Durante la fase de discusión, el equipo tiene la oportunidad de aclarar malentendidos en los requisitos, lo que puede llevar al equipo a evitar que se introduzca un error en la aplicación, lo que es mucho más barato que tener que depurar, diagnosticar y arreglar después.
Además, la fase de «discusión» puede llevar al equipo a descubrir que lo que parecía una simple historia de usuario es, en realidad, mucho más compleja. En este caso, el equipo, junto con el interesado, puede optar por dividir la historia en dos o más historias.
El resultado de esta fase son las pruebas de aceptación en forma de frases o tablas en inglés sencillo que puedan ser entendidas por todos los miembros de la organización.
Destilar
La segunda fase consiste en convertir las pruebas producidas en el paso anterior en un formato compatible con la herramienta de pruebas de aceptación que se esté utilizando. Dependiendo de la herramienta, estos formatos incluyen:
-
tablas
-
páginas wiki
-
o incluso código en un DSL (lenguaje específico del dominio)
El resultado de esta fase son las pruebas de aceptación. Sin embargo, no están del todo listas para su ejecución, como verás.
Desarrollar
En este punto, las pruebas producidas en la etapa anterior no pueden probar realmente el sistema bajo prueba. No son más que esqueletos, en esta etapa; necesita conectarlos al código de prueba real que ejercitará el código de la aplicación.
Los detalles de este cableado varían según las herramientas que se utilicen. Basta con decir que, una vez completado el cableado, las pruebas fallarán, ya que las características que están probando aún no existen.
A continuación, los desarrolladores implementan la función, de acuerdo con las especificaciones recogidas en la fase de «discusión» y que se convirtieron en pruebas en la fase de «destilación».
Demostración
Después de que los desarrolladores implementen la función, la demuestran a las partes interesadas. Celebrar una reunión al final de cada ciclo en la que el equipo discute el producto y/o cómo mejorar el propio proceso es una característica muy común de muchas metodologías ágiles. Por lo tanto, la fase de demostración de ATDD encaja perfectamente con eso.
Una vez completada la implementación, los probadores también pueden realizar algunas pruebas exploratorias manuales. Dichas pruebas pueden encontrar defectos, pero también espacio para mejoras que pueden convertirse en otras historias.
Ejemplo de desarrollo basado en pruebas de aceptación
A continuación, le mostraremos un breve ejemplo de desarrollo basado en pruebas de aceptación.
La historia del usuario
Para este ejemplo, supongamos que está trabajando en un sitio web de comercio electrónico y que necesita implementar un carrito de la compra. En las metodologías ágiles, los requisitos suelen expresarse como historias de usuario. Una plantilla común para las historias de usuario es la siguiente:
Como
quiero
Para que pueda
Así, la historia de usuario para el carrito de la compra podría ser la siguiente:
Como comprador
Quiero poder añadir artículos a mi cesta de la compra
Para poder comprarlos
Discutir: Elaboración de los criterios de aceptación
Durante la fase de «discusión», los desarrolladores y los probadores hacen tantas preguntas como sea posible al experto en la materia o a la parte interesada en el negocio, con el objetivo de encontrar puntos ciegos en los requisitos, aprender sobre los caminos felices y tristes, y descubrir casos límite.
He aquí algunos ejemplos de posibles preguntas:
-
Si añado otra instancia del mismo producto a la cesta, ¿debe aumentar el número o añadirlo como un nuevo artículo?
-
Hay un límite en el número de unidades del mismo producto que puedo añadir a mi cesta de la compra?
-
¿Existe un límite en el número de artículos que puedo añadir a mi cesta?
Sobre la base de los resultados de la discusión, los probadores y los desarrolladores podrían elaborar la siguiente tabla en la que se detallan los escenarios de las pruebas de aceptación:
_____________________________
| Escenario inicial | Acción | Resultado esperado |
| Cesta vacía | Añadir el producto «Libro de Desarrollo Dirigido por Pruebas por Ejemplo», que cuesta $29, a la cesta | La cesta debe contener un artículo y el total debe ser de 29 dólares. |
| Cesta con un producto («libro desarrollo dirigido por pruebas por ejemplo’» que cuesta 29 dólares) | Eliminar el artículo de la cesta. | Cesta vacía. Total de 0. |
| Cesta con 3 unidades del mismo producto. | Añadir otra unidad del mismo producto. | Cesta todavía con tres artículos. Se muestra un mensaje diciendo que los clientes no pueden comprar más de tres artículos del mismo producto. |
_____________________________
Destilar: convertir los criterios en pruebas automatizadas
En la fase de destilación, los desarrolladores y probadores convierten las pruebas de aceptación escritas en lenguaje sencillo en formatos compatibles con las herramientas de automatización que utilizan.
Veamos cómo sería esto, para nuestro ejemplo, utilizando dos herramientas/formatos diferentes.
Fitnesse
Fitnesse es una de las herramientas más populares para las pruebas de aceptación automatizadas. Es única entre otras herramientas de pruebas por el peculiar formato que adopta para expresar las pruebas: tablas en un Wiki.
Src: assertselenium.com
Este es el aspecto que podría tener una tabla de Fitnesse para probar el escenario de «añadir artículos a un carrito»:
La tabla de arriba no es una simple tabla. Son pruebas reales que se pueden ejecutar. Sin embargo, un intento de ejecutarlas da como resultado el siguiente error:
Todavía no tenemos un fixture, es decir, una clase real que «pegue» nuestro test de Fitnesse al código real.
Lenguaje Gherkin (Cucumber)
Veamos ahora cómo podríamos representar los mismos criterios de aceptación utilizando Gherkin, que es el lenguaje especial que utiliza la herramienta Cucumber.
Usando Gherkin, los usuarios pueden describir escenarios usando una plantilla común, conocida como given-when-then:
Given
When
Then
He aquí un ejemplo:
Función: Cesta de la compra
Los compradores necesitan poder añadir artículos a sus carros
Escenario: Añadir un producto a una cesta vacía
Dado que mi cesta está vacía
Cuando añado un producto llamado «Libro TDD por ejemplo» que cuesta 29 dólares a mi cesta
Entonces mi carrito debería contener ese producto
Y el total debería ser de 29 dólares
Al intentar ejecutar la prueba anterior se obtiene un resultado similar al que se ha visto con Fitnesse:
Dice que al escenario le faltan pasos, y luego va más allá y nos da consejos sobre cómo rellenar realmente esos espacios en blanco.
Desarrollar: Cableado de las pruebas e implementación de la función
Para el ejemplo anterior, así es como podríamos rellenar los espacios en blanco:
Given(«mi carrito está vacío», () -> {
this.cart = new ShoppingCart();
});
Cuando(«añado un producto llamado {cadena} que cuesta ${int} a mi carrito», (Cadena, Entero int1) -> {
this.product = new Product(string, int1);
this.cart.add(this.product);
});
Then(«mi cesta debería contener ese producto», () -> {
assertEquals(1, this.cart.getItemsQuantity());
assertEquals(this.product, this.cart.items[0]);
});
Then(«el total debe ser ${int}», (Integer int1) -> {
assertEquals(int1, this.cart.total);
});
Estamos utilizando variables de instancia para mantener una instancia de la clase ShoppingCart, que representa -lo has adivinado- nuestro carrito de la compra. Esta clase podría -y debería- ser desarrollada utilizando el enfoque de «primero la prueba» (TDD).
Como puedes ver, Cucumber es lo suficientemente inteligente como para reemplazar el nombre y el precio del producto con marcadores de posición, que luego se convierten en variables. De esta manera, podemos parametrizar esas pruebas, reutilizando la misma lógica con un número de valores de entrada diferentes.
Similitudes y Diferencias
Ahora vamos a discutir cómo ATDD es similar o diferente de otras prácticas.
Desarrollo impulsado por pruebas de aceptación frente a desarrollo impulsado por pruebas
El desarrollo basado en pruebas de aceptación se compara a menudo con el desarrollo basado en pruebas. Obviamente, están relacionados, pero ¿cómo se comparan ambos?
TDD -desarrollo dirigido por pruebas- es una metodología en la que los desarrolladores comienzan el desarrollo escribiendo una prueba unitaria que falla y sólo entonces escriben el código de producción para que la prueba pase.
Mediante el uso de TDD, los desarrolladores pretenden crear un código limpio y sencillo, compuesto por módulos poco acoplados, lo que conduce a una mayor capacidad de mantenimiento. Sin embargo, TDD es un enfoque centrado en el desarrollador que se basa en las pruebas unitarias. Como se ha visto, las pruebas unitarias pueden llevar al problema de implementar correctamente las características equivocadas.
ATDD no está centrado en el desarrollador, sino que fomenta la colaboración entre los desarrolladores y otros miembros del equipo, incluso los que no tienen conocimientos de codificación.
Se puede y se debe utilizar TDD y ATDD juntos. Al principio de cada iteración, comience por crear pruebas de aceptación automatizadas basadas en las discusiones con el experto en el dominio.
Cuando llegue el momento de implementar el código de producción, utilice TDD para probar el desarrollo de dicho código. En otras palabras: TDD puede ser aprovechado como un ciclo «interno» dentro de las fases generales de ATDD.
Desarrollo impulsado por pruebas de aceptación frente a desarrollo impulsado por el comportamiento
El BDD -desarrollo orientado al comportamiento- fue introducido originalmente por Dan North como sustituto del TDD. Sintió que la palabra «prueba» era problemática, y buscó crear un nuevo vocabulario centrado en los comportamientos y los escenarios. Así, BDD se originó en el nivel de las pruebas unitarias.
Sólo cuando un amigo le señaló que su enfoque sonaba a análisis, empezó a aplicar el enfoque a los requisitos.
Cuando se compara con el desarrollo impulsado por pruebas de aceptación, BDD tiene un enfoque más fuerte en la creación de una comprensión compartida del comportamiento esperado del sistema. Los conceptos del libro Domain Driven Design de Eric Evans -como el lenguaje ubicuo- también influyeron mucho en el desarrollo de BDD.
ATDD por otro lado, fue creado desde el principio con un enfoque en las pruebas de aceptación y la automatización de pruebas.
Errores comunes
Las herramientas ATDD pueden ser una fuente de complejidad/curva de aprendizaje. Por ejemplo, Fitnesse requiere que la gente utilice su lenguaje de marcado. Aunque hay alternativas -como crear las pruebas utilizando una hoja de cálculo de Excel y luego importarlas a Fitnesse- no se puede negar que hay cierta complejidad.
Para implementar con éxito no sólo ATDD, sino las pruebas de aceptación en general, se necesitará formación y tutoría para que la gente esté preparada para realizar lo que se espera de sus funciones. También necesitará una defensa o evangelización efectiva para que todos estén a bordo y listos para aplicar el enfoque.
Sin todo ello, es probable que los beneficios sean limitados.
Cómo empezar
¿Cómo empezar con la ATDD? He aquí algunos pasos prácticos.
-
Formar a todo el mundo sobre el tema para que esté en sintonía. Empiece por asegurarse de que todos los miembros de la organización tengan acceso a los materiales de formación para que puedan formarse en materia de ATDD.
-
Formar a todo el mundo en las habilidades correspondientes a sus funciones y responsabilidades. La implementación de ATDD requiere habilidades muy específicas, incluyendo las sociales: saber cómo discutir y colaborar con los expertos del dominio, por ejemplo. Por supuesto, también se requieren habilidades técnicas, como la competencia de las herramientas de prueba.
-
Familiarizarse con los requisitos en formato de historias de usuario. Las historias de usuario son sin duda una de las bases de ATDD. Es crucial que todos los miembros del equipo se sientan cómodos leyendo y también escribiendo requisitos de software utilizando este formato. Más adelante, se debería ampliar esto a ser también competente en el lenguaje Gherkin.
-
Durante la reunión inicial al comienzo de cada iteración, comience a practicar la extracción de escenarios/criterios de aceptación de las partes interesadas y escriba pruebas en inglés sencillo con ellos. No es necesario utilizar un formato o lenguaje específico para esto.
-
Después de mejorar el paso anterior, busca un tutorial o guía sobre un marco específico de pruebas de aceptación ATDD. Adopta el marco y comienza a implementar las pruebas de aceptación según el ciclo ATDD.
-
Evaluar periódicamente el enfoque y adaptarlo cuando sea necesario.
Más información
-
Desarrollo dirigido por pruebas: Por ejemplo, por Kent Beck
-
ATDD por ejemplo: Una guía práctica para el desarrollo basado en pruebas de aceptación, por Markus Gärtner
-
Impulsar el desarrollo con pruebas: ATDD y TDD – Documento de Elisabeth Hendrickson
-
Desarrollo dirigido por el comportamiento (BDD): La creación de software útil que los clientes quieren
Ofrezca un software que resuelva los problemas de sus usuarios
Por desgracia, es habitual que los equipos de desarrollo creen software que no hace lo que el cliente realmente pidió. El desarrollo orientado a las pruebas de aceptación trata de resolver este problema, utilizando la automatización de pruebas para capturar los requisitos del usuario en un formato bien entendido por todos.
Para poder aprovechar las ventajas de ATDD, hay que tener un conocimiento sólido de sus fundamentos. Esto incluye temas como las historias de usuario, como has visto.
Si no estás familiarizado con el concepto de historias de usuario -o incluso si lo estás, pero quieres refrescar un poco tus conocimientos- echa un vistazo a nuestro artículo sobre esta popular técnica.
Signup for updates!
[wpforms id=»8824″]
¡La vida es buena cuando sus equipos ágiles están sincronizados!
Solicite una demostración personalizada de SwiftEnterprise.
