Behavior-driven development (BDD)

Nuevo enfoque para pruebas unitarias y pruebas de aceptación

Metodología de "afuera hacia adentro". Se inicia en el exterior mediante la identificación de los resultados del negocio, y luego profundiza en el conjunto de características que les permita lograr esos resultados.


Cada característica se captura como una "historia", que define el ámbito de aplicación de la función junto con sus criterios de aceptación.

BDD toma la posición que el equipo puede convertir la idea de un requerimiento en un código implementado, probado, listo para ser desplegado en producción de una manera sencilla y eficaz, siempre y cuando el requisito es suficientemente específico y todos los involucrados sepan lo que está pasando.


Para ello, necesitamos una manera de describir el requerimiento de tal manera que todos los stakeholders o involucrados tengan una comprensión común del alcance de dicho requerimiento.

Big image

¡Eso no es lo que pedí! ¡Me olvidé contarles algo!

Historia de Usuario

Tiene que ser una descripción de un requisito y su beneficio para el negocio, y un conjunto de criterios con los que todos estamos de acuerdo que es “lo que el cliente necesita". Esta es una definición más rigurosa que en otras metodologías ágiles , donde es el requerimiento de plantea como una "promesa" o una "descripción de una característica" .


BDD proporciona un formato simple estandarizado para escribir las historias de usuario y especificar el comportamiento deseado:

BDD vs TDD (explained)

Título

Es una línea que describe la historia, debe ser claro y explícito.


Como un/a [rol]

Es el rol del proyecto/negocio, a quien va destinado el beneficio de implementar la historia, es el stakeholder o involucrado directo de la misma.


Yo quiero [funcionalidad]

Cual es el beneficio directo o resultado que el principal involucrado o stakeholder quiere tener con la implementación de la historia.


Para que [beneficio]

Cual es el valor de negocio agregado que el principal involucrado va a tener con la historia.

Recomendaciones

  • Una historia debe ser el producto de una conversación que implica a varias personas. Un BA habla con un referente del negocio acerca de la necesidad o requisito , y lo ayuda a enmarcarlo como una historia narrada (con distintas técnicas de elicitación de requerimientos, las que vienen usando hasta ahora).
  • Luego todo el equipo puede sumar su aporte: un integrante del equipo de QC puede ayudar a definir el alcance de la historia (criterios de aceptación) mediante la determinación de que los escenarios. Un referente técnico o miembro del equipo de Desarrollo proporcionará la visión técnica del impacto del requerimiento y como diseñarlo.
  • Luego todo el equipo va a participar de la estimación aproximada de la cantidad de trabajo necesario para la historia , y proponer enfoques alternativos. Esto probablemente será un proceso iterativo .
  • El cliente tendrá una idea de lo que quiere, pero por lo general no sabe cómo plasmarla. Con la ayuda del equipo se puede comprender el costo / beneficio de cada escenario y hacer un análisis de los mismos (factibilidad técnica).

También puedes visitar...