Si te acercas a algún foro de Testing, Testing Ágil, QA Ágil, Agilidad en general, o algún foro que aún comenta la osadía de usar el nombre “calidad software”, y no estás muy metido en el tema, es posible que pienses que te has confundido y te has colado en un foro de Chino Mandarín, cuando todo el mundo empiece a combinar frases con los acrónimos ATDD, BDD, TDD, etc.
Si eres un sufridor del software desde hace años no te sorprenderás, ya sabes que somos muy dados a usar, y disparar, siglas una tras otra.
Respecto al tema que nos concierne hoy, ya le hemos dicado un número considerable de post a intentar aclarar estos términos, quizá recuerdes, y sino ese es el mejor momento de leerlos, los siguientes post:
Entendiendo qué es BDD (Behavior-Driven Development) (I), la parte II, la parte III y la parte IV y la parte V.
Y, más recientemente, el de ¿Qué es eso de ATDD?
Vamos con otro más, en esta ocasion relativo a…
Bueno… ¿Y en qué se diferencian ATDD y BDD?
En algunos puntos las diferencias están bastante claras, con poco que conozcas los anteriores, en otros no te creas que tanto. Verás…
La postura mayoritaria es que ATDD son pruebas de aceptación que se hacen con los usuarios (o sus representantes, véase el Product Owner) antes de comenzar a desarrollar, buscan así ser un elemento de comunicación y comprensión compartida, y estas que se automatizan.
Un mensaje aquí, no para todo el mundo (me incluyo) en el ATDD es necesaria esa parte de “se automatizan” (véase el libro de Lean-Agile Acceptance Test Driven Development), que se automaticen todas las pruebas derivadas del ATDD.
Por otro lado, BDD busca un lenguaje común para unir la parte técnica y la de negocio, y que sea desde ese lenguaje común desde donde arranque el Testing, destacando el Testing unitario y, desde ahí, el desarrollo, nos orientamos entonces, como parece razonable a un TDD.
Así, mayoritariamente, se ve a BDD como el puente, el “pegamento”, el camino, para unir un ATDD con un TDD. Como dice este artículo en Agille Alliance, BDD combina practicas de TDD y ATDD.
Pero no podía ser tan fácil. A pesar de lo anterior, no obstante, hay quien dice que BDD y ATDD son lo mismo. En el mismo libro ATDD by Example de Markus Gärtner dice explícitamente que ATDD es conocido por varios nombres, destacando algunos como:
– Behavior-Driven Development (BDD)
– Specification by Example
– Agile Acceptance Testing
– Story Testing
Ya sabes, un clásico en lo nuestro, no existen definiciones únicas, asi que quédate con la idea y no te pierdas en detalles terminológicos.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Excelente artículo. Se me complicaba separar BDD y ATDD. Son técnicas muy interesantes para el desarrollo de sistemas, sobre todo para evitar problemas de comunicación entre usuarios finales, analistas y desarrolladores.
Saludos.