Si estás familiarizado con TDD entonces ATDD es de alguna manera TDD con un nivel más alto de pruebas y con más partes interesadas involucradas, en otras palabras, es más una prueba de aceptación que pruebas unitarias. Si quieres saber más sobre TDD entonces por favor revisa el siguiente post:
El desarrollo dirigido por pruebas de aceptación (ATDD) es una metodología de desarrollo basada en la comunicación entre los clientes del negocio, los desarrolladores y los probadores. ATDD engloba muchas de las mismas prácticas que la especificación por ejemplo, el desarrollo impulsado por el comportamiento (BDD), el desarrollo impulsado por el ejemplo (EDD) y el desarrollo impulsado por el soporte, también llamado desarrollo impulsado por la prueba de historias (SDD). Todos estos procesos ayudan a los desarrolladores y probadores a entender las necesidades del cliente antes de la implementación y permiten a los clientes poder conversar en su propio lenguaje de dominio.
Ampliamente implementado en los equipos ágiles, el ATDD es una práctica en la que los analistas de negocio, los desarrolladores, los probadores y los usuarios trabajan juntos para definir los criterios de aceptación de cada historia (o característica) en una etapa temprana del proceso de desarrollo (antes de que comience la codificación). Este enfoque permite que todas las partes interesadas tengan y mantengan el mismo nivel de resultados esperados antes de que cualquier desarrollador comience a codificar.
Sé que todos hemos oído este estereotipo de «Los desarrolladores no se preocupan por la especificación y los probadores no quieren hacer la automatización», pero con ATDD esto ahorrará una gran cantidad de tiempo y dinero perdido, asegurando que los desarrolladores están más involucrados en las primeras etapas de la especificación y los probadores están automatizando las pruebas de aceptación.
¿Cómo se implementa ATDD en la «vida real»?
¿Estás usando SCRUM? Si es así, entonces ya estás haciendo la mayor parte del trabajo en ATDD. Si no es así, el siguiente ejemplo debe alimentar tu curiosidad :
Ejemplo
Supongamos que el propietario del producto o el cliente solicitó la siguiente característica en nuestra aplicación móvil: «Como usuario quiero saltarme la pantalla de login para poder usar la aplicación de forma anónima» Después de revisar esta petición con todo el equipo (Analista de negocio, Desarrolladores, Testers…) y con más detalles añadidos a la historia o a la característica, tendremos unas pruebas de «aceptación» o «funcionales» similares a esta (Ten en cuenta que esto es solo un ejemplo, faltan muchas pruebas de aceptación para esta característica):
- Criterio de aceptación 1: La aplicación acepta opcionalmente login/contraseña para iniciar sesión
- Criterio de aceptación 2: El botón bypass permite al usuario navegar dentro de la aplicación sin necesidad de iniciar sesión.
- Criterio de Aceptación 3: Cuando se selecciona el botón bypass la aplicación no almacena ni muestra ninguna información específica del usuario.
- Criterio de Aceptación 4: Cuando se utiliza el login/contraseña, la GUI de la aplicación debe ajustarse a la configuración del usuario.
Beneficios
1- Alineación cliente-vendedor : Al tener los criterios de aceptación anteriores como información de entrada, nosotros (todos los miembros del equipo) estamos ahora seguros de que la aplicación mantendrá su funcionalidad de login/contraseña y sólo añadirá un botón para permitir al usuario saltarse la pantalla de login.
2- Calidad y rentabilidad: Las pruebas anteriores se pueden automatizar fácilmente incluso antes de que los desarrolladores empiecen a codificar.
3- Tiempo de comercialización: Una vez implementadas las pruebas los desarrolladores pueden validar sus tareas requeridas antes de anunciar que han terminado.
ATDD no requiere ninguna herramienta específica. Es importante saber, que NO todas las pruebas de aceptación deben ser automatizadas. La automatización de las pruebas depende de múltiples aspectos como: retos técnicos, plazo y coste.
¿Se recomienda alguna herramienta?
ATDD no requiere ninguna herramienta específica. Es importante saber, que NO todas las pruebas de aceptación deben ser automatizadas. La automatización de las pruebas depende de múltiples aspectos como: los retos técnicos, la fecha de entrega y el coste.
En esta sección te daré sólo una visión general de las herramientas de automatización más utilizadas en ATDD:
FitNess: El marco de pruebas de aceptación y wiki independiente totalmente integrado
Robot framework: marco de automatización de pruebas genérico para pruebas de aceptación y desarrollo dirigido por pruebas de aceptación (ATDD)
Calabash: Pruebas de aceptación automatizadas para aplicaciones móviles – Tenga en cuenta que este marco puede no soportar la última versión del sistema operativo (por encima de Android O )