BDD: Colaborando de Verdad con Negocio

BDD: Colaborando de Verdad
con Negocio
Eduardo Riol

¿Quién soy?
Eduardo Riol, Líder Técnico de QA & Testing en
atSistemas.
Comencé desarrollando en entornos Java y .NET hace
alrededor de una década pero he dedicado los últimos
siete años a la Calidad del Software, tanto orientada
al producto como a los procesos de desarrollo.
Actualmente mis intereses se centran en el control de
la deuda técnica, BDD y la integración de las
actividades de QA en entornos Agile y DevOps.
twitter.com/eduriol
github.com/eduriol
linkedin.com/in/eduriol

Houston, we have a problem!
“Esto no es lo que habíamos pedido” ¿Nos suena?

Houston, we have a problem!
“Esto no es lo que habíamos pedido” ¿Nos suena?
El teléfono
escacharrado
The Gossips, Norman Rockwell, 1948

Nos enfocamos en construir el software
CORRECTAMENTE…
Testing funcional
Tests unitarios
Testing de rendimiento
Testing de integración
Análisis estático Hacking ético
Auditorías de procesos
UAT

… ¿pero estamos construyendo el software CORRECTO?
Features Used
The Standish Group estimate of features used in custom application development, 2014
Hardly Ever
50%
Often
20%
Infrequently
30%

No confiamos en las releases
La mayoría de las veces no
contamos con una suite de tests
de aceptación lo suficientemente
robusta y completa como para
fiarnos de ella

Falta de documentación
The Agile manifesto
Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan
We are uncovering better ways of
developing software by doing it
and helping others do it. Through
this work we have come to value:
That is, while there is
value in the items on the
right, we value the items
on the left more.

Falta de documentación
¿Cuántas veces habéis acabado un proyecto en el que la documentación técnica
refleje lo que hace realmente el software?
Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan
We are uncovering better ways of
developing software by doing it
and helping others do it. Through
this work we have come to value:
That is, while there is
value in the items on the
right, we value the items
on the left more.
The Agile manifestoThe Agile manifesto

¿Y la colaboración dentro del equipo?
Tenemos problemas
de calidad
No es mi problema, de la
calidad se encarga la gente
QA, ¿no?

¿Y la colaboración dentro del equipo?
¿Desarrollo? Creo que son los que se
sientan en el zulo ese de la cuarta
planta
Tenemos problemas
de calidad
No es mi problema, de la
calidad se encarga la gente
QA, ¿no?
La gente de Desarrollo no para de
devolverme el software sin corregir el
bug

Este problema parte de aquí
Como fases separadas, estimadas y
planeadas al principio del proyecto
• Análisis
• Desarrollo
• Testing
• Operaciones

BDD: Cómo colaboran Desarrollo y Negocio
BDD es un modelo de colaboración entre los usuarios de Negocio
y el equipo de Desarrollo…
… que consiste en establecer conversaciones basadas en ejemplos
concretos de uso de la aplicación, con el objetivo de reducir
malentendidos y asunciones…
… descubriendo en el proceso las features que realmente aportan
valor

¿Entonces qué es (y qué no) BDD?
• Escribir requisitos en lenguaje
Gherkin
• Automatizar pruebas con
Cucumber
• Documentar funcionalidades
después de programarlas
• Modelo de colaboración
• Un proceso de descubrimiento
• Entender necesidades de
Negocio
• Describir el software con
ejemplos
• ATDD bien hecho
Qué es Qué no es

BDD: Cómo colaboran Desarrollo y Negocio
• Los ejemplos que describen una nueva
feature se plasman en un lenguaje sencillo
y común, sin ambigüedades (por ejemplo
Gherkin)
• El equipo de Desarrollo transforma estos
ejemplos en una serie de especificaciones
ejecutables como tests automáticos
• Una feature del software está acabada
cuando todas sus especificaciones se
ejecutan correctamente
BDD
TDD
Escribir un test que falla
N ciclos

Three amigos
1. El PO habla con
Negocio sobre sus
necesidades
2. El PO, un Dev y un Tester
se reúnen para elaborar los
escenarios conjuntamente
4. Los escenarios guían al
desarrollador y actúan como
tests automatizados
3. El tester implementa los
escenarios como tests de
aceptación
5. Los tests automatizados
aportan feedback sobre el
progreso y documentan la
aplicación

Un escenario de colaboración
Queremos que nuestra aplicación requiera un
password que tenga que tener al menos 8
caracteres, un número y una mayúscula
Password Seguridad Aceptable?
secret Débil No
password Débil No
password1 Débil No
aBcdEfg1 Débil No
qwertY12 Débil No
dJeZDip1 Medio Sí
GaviotaErizo Fuerte Sí
GaviotaErizoCatapulta Muy fuerte Sí
¿No querrás decir que quieres
que la aplicación requiera un
password seguro?

Un escenario de colaboración
Queremos que nuestra aplicación requiera un
password que tenga que tener al menos 8
caracteres, un número y una mayúscula
Password strenght, xkcd, Randall Munroe
Password Seguridad Aceptable?
secret Débil No
password Débil No
password1 Débil No
aBcdEfg1 Débil No
qwertY12 Débil No
dJeZDip1 Medio Sí
GaviotaErizo Fuerte Sí
GaviotaErizoCatapulta Muy fuerte Sí
¿No querrás decir que quieres
que la aplicación requiera un
password seguro?

Descubriendo nuestro Negocio
“In software development, ignorance is the constraint. You know a lot more about the
best way to build a particular solution after you’ve finished building it, but by then it’s
too late to take advantage of your knowledge.”
John Ferguson Smart, BDD in action, 2015

Descubriendo nuestro Negocio: conversaciones
¿Me puedes dar un ejemplo de un viajero
moviéndose entre dos estaciones?
Claro, por ejemplo puede ir desde
Nuevos Ministerios hasta Gran Vía

¿Y cómo sería eso?
Bueno, habría que avisar al usuario de que tome
la línea 10. Después que se baje en Alonso
Martínez y cambiar a la línea 5.

¿No hay ninguna otra forma de moverse entre
estas dos estaciones?
No, sería absurdo, ésta es la forma más
rápida.
¡Bueno espera, tienes razón! Según el
momento del día y si el siguiente tren
en Nuevos Ministerios es de la línea 6,
puede ser más rápido tomar esa línea
hasta Cuatro Caminos y allí cambiar a
la 1
¿Seguro?

Implementando BDD: Describiendo escenarios
ESCENARIO
Envío del formulario de contacto
Dado que Juan Pérez entra al formulario de contacto
Y rellena los campos con sus datos y el mensaje
Y acepta las cláusulas legales
Cuando envía la consulta
Entonces se muestra la confirmación de
la correcta recepción del mensaje
Dado / Given: Define el contexto en el cual se
ejecuta el escenario. En este paso se
determinan las condiciones de partida del
ejemplo.
Cuando / When: Es la acción que desata el
ejemplo. Consiste en la interacción con la
aplicación, normalmente de un usuario, cuyo
comportamiento se quiere validar.
Entonces / Then: En este paso se define el
resultado esperado por Negocio. La condición
que se debe cumplir para que el escenario se
haya ejecutado correctamente.

Implementando BDD: Describiendo escenarios
Característica: Transfiriendo dinero entre cuentas
Para gestionar mi dinero con mayor eficacia
Como un cliente del banco
Quiero transferir fondos entre mis cuentas
Escenario: Transfiriendo dinero a una cuenta de ahorros
Dado que mi cuenta Corriente tiene un balance de 1000.00
Y que mi cuenta Ahorro tiene un balance de 2000.00
Cuando transfiero 500.00 de mi cuenta Corriente a mi cuenta Ahorro
Entonces debo tener 500.00 en mi cuenta Corriente
Y debo tener 2500.00 en mi cuenta Ahorro
Escenario: Transfiriendo con fondos insuficientes
Entonces debo recibir un aviso de ‘fondos insuficientes'
Y debo tener 1000.00 en mi cuenta Corriente
Escenario: Transfiriendo todo el dinero
Y debo recibir un aviso de ‘cuenta corriente a cero'
Una feature es una funcionalidad del
software que da soporte a un objetivo
del negocio. Feature != User Story
Un escenario representa un ejemplo
de uso concreto de la feature. Surgen
a raíz de la colaboración entre los
involucrados y ayudan a minimizar
malentendidos y falsas suposiciones
sobre aspectos concretos de la
feature.

Implementando BDD: Automatizando escenarios

Implementando BDD: Automatizando escenarios
@Given(“^que mi cuenta (.*) tiene un balance de (d+)$")
public void setupInitialAccount(AccountType accountType,
double amount) {
// Setup account
}
@When(“^transfiero (d+) de mi cuenta (.*) a mi cuenta (.*)$")
public void transferAmountBetweenAccounts(double amount, AccountType source, AccountType destination) {
// Perform action
}
@Then(“^debo tener (d+) en mi cuenta (.*)$")
public void checkAccountAmount(double amount, AccountType accountType) {
// Assert amount
}

Testing exploratorio
Niveles de BDD: La pirámide del testing
UI
API / Services
Unit
Prevenir errores / Aportar valor

Testing exploratorio
Niveles de BDD: La pirámide del testing
UI
API / Services
Unit
UI (manual & automático)
API / Services
Unit
Prevenir errores / Aportar valor Detectar errores / Certificar releases

Capa de Flujo de Negocio
private HomePage homePage;
private RecordatoriosPage recordatoriosPage;
@Cuando("creamos un nuevo recordatorio de vacuna")
public void crearRecordatorio() {
this.homePage = new HomePage(this.driver);
this.homePage.load();
this.homePage.irARecordatorios();
this.recordatoriosPage = new RecordatoriosPage(this.driver);
this.recordatoriosPage.crearRecordatorio(this.datosRecordatorio);
}

Capa de Implementación Técnica
Capa de Flujo de Negocio
private HomePage homePage;
private RecordatoriosPage recordatoriosPage;
@Cuando("creamos un nuevo recordatorio de vacuna")
public void crearRecordatorio() {
this.homePage = new HomePage(this.driver);
this.homePage.load();
this.homePage.irARecordatorios();
this.recordatoriosPage = new RecordatoriosPage(this.driver);
this.recordatoriosPage.crearRecordatorio(this.datosRecordatorio);
}
public class HomePage extends PageObject {
@FindBy(linkText = “Recordatorios")
private WebElement linkRecordatorios;
public HomePage(WebDriver driver) {…}
public void irARecordatorios() {
this.linkRecordatorios.click();
}
…
}

BDD a nivel unitario: dirigiendo y definiendo el diseño
Escenario: Los nuevos clientes deben empezar con la tarjeta BRONCE
Dado que Ana López no es clienta de nuestro supermercado
Cuando se registra en el programa de comprador frecuente
Entonces debe comenzar con la tarjeta bronce
BDD Alto
Nivel
BDD Bajo
Nivel

@Cuando("se registra en el programa de comprador frecuente")
public void registra_en_programa_comprador_frecuente() {
comprador = Comprador.conNumero(“123456789”).llamado(nombre, apellido);
}
BDD Alto
Nivel
BDD Bajo
Nivel

}
@Test
public void debe_ser_capaz_de_crear_un_nuevo_comprador() {
Comprador comprador = Comprador.conNumero(“123456789”).llamado(“Ana”, “López”);
assertThat(comprador.getNombre()).isEqualTo(“Ana”);
assertThat(comprador.getApellido()).isEqualTo(“López”);
assertThat(comprador.getNumero()).isEqualTo(“123456789”);
}
BDD Alto
Nivel
BDD Bajo
Nivel

}
public static class CompradorBuilder {
private String numeroComprador;
public CompradorBuilder(String numeroComprador) {
this.numeroComprador = numeroComprador;
}
public Comprador llamado(String nombre, String apellido) {
return new Comprador(numeroComprador, nombre, apellido);
}
}
@Test
public void debe_ser_capaz_de_crear_un_nuevo_comprador() {
Comprador comprador = Comprador.conNumero(“123456789”).llamado(“Ana”, “López”);
assertThat(comprador.getNombre()).isEqualTo(“Ana”);
assertThat(comprador.getApellido()).isEqualTo(“López”);
assertThat(comprador.getNumero()).isEqualTo(“123456789”);
}
BDD Alto
Nivel
BDD Bajo
Nivel

Documentación autogenerada
Objetivos de
Negocio
Features Escenarios
Documentación viva
Informes en tiempo real
Documentación técnica
Validación automática
Especificaciones
Ejecutables
Ayuda a Negocio, QA y Dev a conocer lo que se ha construido
Cuánto se ha hecho y cuánto queda por hacer
Código más fácil de actualizar y mantener
Los escenarios dicen lo que hace la aplicación, o su ejecución falla

BDD en el proceso de construcción del software
La ejecución de los escenarios deben ser parte del proceso de
integración, construcción y despliegue del software.
Cada escenario debe poder ejecutarse de forma separada, sin ningún
orden concreto. No debe haber dependencia entre escenarios.
Los escenarios son un activo más de código a mantener bajo control de
versiones.
El proceso de construcción y despliegue del software también pasa a
ser un proceso de construcción y despliegue de documentación e
informes.

Informes: feature readiness
Una feature se considera lista
para pasar a producción cuando
todos sus escenarios se ejecutan
correctamente.
Feature readiness
A tu negocio le da igual que los tests pasen. Lo que quieren saber es si la funcionalidad
está lista o no para ponerse en producción.

Informes: feature coverage
La cobertura de features muestra
el % de features cuyos
escenarios definidos se ejecutan
correctamente
Feature coverage

¡Ojo!, BDD no es una bala de plata
Implicación de Negocio: necesitamos que los involucrados
se impliquen desde el comienzo.
BDD está pensado para Agile: es un modelo de colaboración
de cara al descubrimiento iterativo de requisitos.
A BDD no le gustan los silos: si la organización
trabaja en grupos aislados y la colaboración no fluye,
desaparece la aclaración progresiva de objetivos.
Riesgo de alto coste en mantenimiento de tests: se requiere
experiencia y conocimiento para diseñar especificaciones
funcionales mantenibles e implementarlas correctamente

¡Llamada a la acción!
Lo que me gusta llevarme de cada evento:
• Nuevos conocimientos
• Desconectar de la rutina
• Conocer gente
• Disfrutar del catering
• Salir con ganas de hacer cosas

¡Llamada a la acción!
Lo que me gusta llevarme de cada evento:
• Nuevos conocimientos
• Desconectar de la rutina
• Conocer gente
• Disfrutar del catering
• Salir con ganas de hacer cosas
Habla con tus usuarios de negocio e invítales a un café: Olvidaos de
definir features de Cucumber solos en vuestro escritorio y poneos
con un cuaderno a definir escenarios conjuntamente con ellos

¡Muchas gracias!
¿Preguntas?

BDD: Colaborando de Verdad con Negocio

Recomendados

Recomendados

Más contenido relacionado

Similar a BDD: Colaborando de Verdad con Negocio

Similar a BDD: Colaborando de Verdad con Negocio (20)

BDD: Colaborando de Verdad con Negocio