BDD en practica (seminario)

Seminario
Jueves 12 de Noviembre de 2014

BDD EN PRACTICA
Antonio Robres Turon
Quality Manager

12 y 13 de noviembre de 2014 Valencia, España 3
Quien soy?
 {Nombre: Toni Robres,
rol: [QA Manager, QA Arquitect],
hobbies: [Leer, Tenis, Testing] }

Introducción
Porque estoy aquí?
oPorque quiero compartir la experiencia aprendida con vosotros.
Que vamos a ver durante el dia de hoy?
oComo escribir buenas especificaciones mediante BDD
Vas a pegarnos el rollo durante 90 minutos?
oEsta es una sesión pràctica donde la mayoría del tiempo vais a
trabajar en grupos y discutir.

Agenda
Introducción a BDD  20’
Presentación del producto y formación de grupos  10’
Plantear las historias de usuario por grupos  15’
Discusión sobre las historias de usuario  10’
Plantear los escenarios de las historias de usuario  20’
Discusión sobre los escenarios y consejos de cómo
crearlos  10’
Preguntas  10’

Introducción
Cuales son los principales problemas en las
especificaciones de producto?
oEspecificaciones pobres
oEspecificaciones incompletas
oFalta de un lenguaje común
oIndefinición de cuando una funcionalidad está acabada.

Introducción
Solución
oCrear especificaciones basadas en ejemplos
oDefinir un lenguaje común
oClara definición de “Acabado”

BDD – Desarrollo guiado por comportamiento
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.

BDD – Desarrollo guiado por comportamiento
BDD no es una herramienta es una manera de trabajar
Usar ejemplos para crear un entendimiento compartido
para evitar incerteza y entregar software que realmente
importa

Como funciona BDD?

Por donde comenzamos
Backlog
oEs una lista de requisitos funcionales y no funcionales
oPriorizado
DEEP:
oDetallado – Estimado – Emergente – Priorizado
INVEST:
oIndependiente – Negociable – Valioso – Estimable – Sized -
Testeable

Historias de Usuario
Una buena historia de usuario es:
oTarjeta
oConversación
oConfirmación
Las historias de usuario deben ser definidas cuando sean
necesarias

Escenarios
Son la confirmación de las historias de usuario
Un escenario es una concrección o ilustración con
ejemplos de una historia de usuario
El conjunto de todos los escenarios describe
completamente el comportamiento de la historia de
usuario

Escenario
Estructura:
oSet up
oPrerequisitos
oProcedimiento
oValidación
oTear-down
Como deben ser los escenarios?
oRapidos – Aislados – Repetibles
oPriorizados

Gherkin
Es un lenguaje de negoció o lenguaje especifico de
dominio, creado para describir el comportamiento de los
escenarios
Usa una estructura para que sea leida por humanos
No necesita herramientas
Sintaxis:
oOrientado por lineas con indentación  Paso
oPuede ser en cualquier lenguaje
oUtiliza indentación y palabras clave para separar las partes

Estructura de Gherkin

FIN TEORIA
Pongamonos manos a la obra!
Me voy a transformar en un cliente!
He descubierto un software revolucionario que cambiara
la manera de aprender de las personas y le he
encontrado un nombre muy muy original!!!

MAQUINA DE APRENDER!!!!

Que es la maquina de aprender
Juego de pregunta – Respuesta
Facil de añadir nuevas preguntas
Con varias categorias
Usa el algoritmo de Leitner para mejorar el aprendizaje
de los alumnos

Algoritmo de Leitner

Como escojo las preguntas?
 Todas las preguntas de la caja 1 son susceptibles de ser preguntadas
 Caja 2  Si la última respuesta correcta ha sido hace más de 12 horas
 Caja 3  Si la última respuesta correcta ha sido hace más de 1 dia
 Caja 4  Si la última respuesta correcta ha sido hace más de 5 días
 Caja 5  Si la última respuesta correcta ha sido hace más de 10 días

Ejemplo
Pregunta Caja Última respuesta correcta
1 1 1 hora
2 1 10 horas
3 1 13 horas
4 1 1 día
5 1 1 semana
6 2 11 horas
7 2 20 horas
8 3 12 horas
9 4 5 minutos
10 4 5 días y 1 hora
oPreguntas disponibles
 1,2,3,4,5
 6
 10
oLa plataforma ha de escoger
aleatoriamente una pregunta
de todas las disponibles

Funcionalidades en el backlog
Crear usuario
Borrar usuario
Modificar usuario
Crear pregunta
Modificar pregunta
Borrar pregunta
Jugar!

Estructura Historia de usuario
Titulo de la historia
Narrativa
oComo [rol]
oQuiero una [funcionalidad]
oPara conseguir un [beneficio]

Tiempo de practicar!
Escribir las historias de usuario de las funcionalidades que
se han planteado
Recordar... El cliente esta con vosotros!
15’

Estructura escenarios
Titulo
Narrativa
oDado [contexto]
oY [Más contexto]
oCuando [ocurre un evento]
oEntonces obtengo [una salida]

Dado...
Definen los prerequisitos
El proposito es dejar el sistema en un estado antes de
que exista la interacción con el sistema
Recordar que los tests son aislados!
oNo deben depender de otro test

Cuando...
El proposito de este paso es describir la acción clave que
el usuario realiza.
Solo se recomienda un paso “Cuando”!

Entonces...
El proposito de este paso es observar las salidas y validar
las hipótesis
En este paso es donde se realizan las verificaciones

Dirigido por datos
A veces necesitamos ejecutar el mismo procedimiento
con diferentes datos
Es posible reutilizar los procedimientos mediante tablas

Dirigido por datos
Escenario: Transferencia de dinero
Dado que tengo < dinero_CC > euros en mi cuenta corriente
Y que tengo <dinero_CA> euros en mi cuenta de ahorro
Cuando transfiero <dinero_a_transferir> de la cuenta corriente a la cuenta de ahorro
Entonces tengo < dinero_despues_CC > euros en la cuenta corriente
Y tengo < dinero_despues_CA > euros en la cuenta de ahorro
Ejemplos
| dinero_CC | dinero_CA | dinero_a_tranferir | dinero_despues_CC | dinero_despues_CA |
| 100 | 20 | 20 | 40 | 80 |
| 50 | 20 | 50 | 0 | 70 |
| 100 | 0 | 10 | 90 | 10 |
| 100 | 0 | 100 | 0 | 100 |

Tiempo de practicar!
Escribir los escenarios de las historias de usuario
15’

Consejos
Escribir las especificaciones antes que la implementación
este acabada
Actualiza las especificaciones
Ordena y prioriza los escenarios
Muestra tu trabajo, observa el de otros, pide feedback y
debate

Evitar...
Hacer ficheros de funcionalidad excesivamente largos
Incluir sets de dato demasiados grandes y / o complejos
No incluyais tecnologias
Tener muchas verificaciones en un escenario
Tener escenarios no repetibles o no aislados

Ventajas
Colaborar y discutir
Documentación viva
Son la entrada a la automatización usando BDD
Facilitan la creación de nuevos test cases

Preguntas?

BDD en practica (seminario)

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Similar a BDD en practica (seminario)

Similar a BDD en practica (seminario) (20)

Más de Antonio Robres Turon

Más de Antonio Robres Turon (9)

BDD en practica (seminario)

Notas del editor