Este documento describe el Behavior Driven Development (BDD) como una metodología ágil para mejorar la calidad del software mediante una mejor comunicación entre las partes interesadas. El BDD define el comportamiento deseado del software a través de escenarios escritos en un lenguaje común (Gherkin) que pueden automatizarse para comprobar que el software funciona como se espera. Siguiendo este proceso, se mejora la comprensión entre equipos, se reducen los riesgos y los costes de cambios posteriores.

1. BDD para la mejora de la calidad
software

2. Enrique Sánchez
Technical Team Lead @ Medianet Software

3. Más de 3 años de experiencia en empresas como
Evangelista BDD

4. ¿Por qué esta charla?

5. Hay dos problemas fundamentales en
el desarrollo de software
!
1. Construir el software mal
2. Construir el software incorrecto

6. Coste de un
cambio
Tiempo

7. Hay que reducir al máximo
los riesgos

8. Malentendidos gastan tiempo
Defectos provocan retrasos
Fallos en la planificación dañan tu reputación

9. “
”
56% of all bugs can be traced to errors made during the
requirement stage.
Tom deMarco

10. “ ”
68% failed projects
Standish Group Report 2009

11. “
”
I had a problem (…) Programmers wanted to know where to
start, what to test and what not to test, how much to test in
one go, what to call their tests, and how to understand why a
test fails.
Better Software, March 2006
Dan North
@tastapod

13. Engineering
Product

14. Centrémonos en la comunicación
Definamos un lenguaje común
Anticipémonos a los problemas
Mantengamos una buena documentación

15. Behavior Driven Development

16. “
”
BDD is a second-generation, outside-in, pull-based, multiple-
stakeholder, multiple-scale, high-automation, agile
methodology. It describes a cycle of interactions with well-
defined outputs, resulting in the delivery of working, tested
software that matters.
Agile specifications, BDD and Testing eXchange, November 2009
Dan North
@tastapod

17. Definamos lo que el software debe de hacer en términos del
comportamiento deseado

18. Definamos lo que el software debe de hacer en términos del
comportamiento deseado
BUSINESS

19. Outside - InDesde negocio a desarrollo

20. Comunicaciónentre stakeholders, producto, desarrollo, testing…

21. Gherkin

22. Creamos una narrativa
¿Por qué?
Para tener un lenguaje común que
todos entendamos
¿Cómo?
Escenarios y Pasos

23. Narrativa
Ejemplo Describe
ImplementaDiseña

24. Feature
In
order
to
definir un objetivo
As
a
Rol/actor
I
want
to descripción de lo que se va a hacer

25. Scenario
Given
setup
When
interacción/cambio/acción
Then comprobamos que todo fue como esperamos

26. ¿Y en la vida real?

27. ¿Qué herramientas usamos?
Nosotros usamos Cucumber
Framework BDD escrito en Ruby
¿Por qué?
Mucha documentación y fácil de
aprender

28. ¿Cómo funciona?

29. ¿Qué proceso seguimos?Que pasos seguir para implementar BDD

30. Definimos los Acceptance Criteria

31. Features / Scenarios

32. Creamos una definición formal de un
escenario

33. Hacemos algo de magia…

34. Creamos tests automáticos que hagan
que prueben la funcionalidad

35. Creamos el entorno del proyecto

37. Evoluciona y adáptate

38. Personas antes que herramientas
Adapta las herramientas a tu proceso no al revés

39. Podemos mejorar la comunicación
Mantenemos a la gente involucrada
Simplificamos el proceso
Tenemos documentación actualizada
Entonces…

40. Preguntas?
Gracias!

41. Enrique Sánchez | hola@enrique-sanchez.me | @EnriqueSanchezB