Presentación para el meetup del blog tecnológico enmilocalfunciona.io sobre BDD y TDD

1. BDD & TDD:
aprovecha su
poder

2. ¿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

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

4. 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

5. … ¿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%

6. 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

7. ¿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

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

9. 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

10. ¿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
Qué es Qué no es

11. 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

12. Three amigos
Negocio QA
Dev

13. 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?

14. 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.

15. Implementando BDD: Automatizando escenarios
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
@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
}

16. 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

17. ¿Pero entonces BDD y TDD son lo mismo?
My experience is that BDD’s emphasis on collaboration, and the use
of business-readable, executable specifications, means that this
shared language develops much more quickly. When everyone is
involved in writing documentation that describes what the system
should do, they all get a chance to learn the language of the
domain together.
So BDD really isn’t all that different to TDD. What BDD adds is a
clear emphasis on what it takes to make TDD succeed.
Matt Wynne

18. 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.

19. ¡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

20. Tecnologías para BDD

21. ¡Muchas gracias!
¿Preguntas?