Inventor: Dan North
Behavior Driven Development es un conjunto de prácticas destinadas a mejorar la colaboración entre desarrolladores, responsables de calidad y partes interesadas no técnicas en torno a la calidad del software en el contexto de la producción de un producto de TI.
Dan North creó BDD en respuesta a TDD, lo que podría ser una fuente de frustración para los desarrolladores: ¿qué debo probar en esta historia de usuario? ¿Qué nomenclatura usar?…
Para un Product Owner, la práctica de BDD se expresa al incluir en la descripción funcional de un elemento un conjunto de escenarios de pruebas funcionales precisas, objetivas, integrales, inequívocas y exhaustivas destinadas a describir la funcionalidad.
Más específicamente, el BDD destaca:
- El uso de oraciones comprensibles en la creación de casos de prueba. Esta práctica ayuda a leer mejor el código y crea un vínculo con la funcionalidad esperada.
- El uso de términos relacionados con el comportamiento. «ShouldCreditAccount» te hace preguntarte si el resultado esperado es consistente y si es realmente necesario.
- El uso de lenguajes de pseudoprogramación para describir pruebas (Gherkin, por ejemplo). El Product Owner o los testers pueden escribir criterios de aceptación por sí mismos y, por lo tanto, limitar los malentendidos con el equipo de desarrollo.
En el marco de Product Owner, el BDD permite una mayor fluidez en la comunicación de los criterios de aceptación de una historia de usuario. De hecho, estos serán integrados fácilmente por una persona no técnica (ver Gherkin para un ejemplo), y también pueden usarse como documentación.
Para saber más: descarga el libro de Agile Product Management
Copiar el enlace
