Cas 2017 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 Ever50%

Often20%

Infrequently30%

No confiamos en las releases

No confiamos en las releases

La mayoría de las veces no contamos con una suite de testsde 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

Negocio QA

Dev

Three amigos

1. El PO habla con Negocio sobre sus

necesidades

2. El PO, un Dev y un Testerse 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 Nopassword Débil Nopassword1 Débil NoaBcdEfg1 Débil NoqwertY12 Débil NodJeZDip1 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 Nopassword Débil Nopassword1 Débil NoaBcdEfg1 Débil NoqwertY12 Débil NodJeZDip1 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 contactoDado que Juan Pérez entra al formulario de contactoY rellena los campos con sus datos y el mensajeY acepta las cláusulas legalesCuando envía la consultaEntonces se muestra la confirmación dela 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 cuentasPara gestionar mi dinero con mayor eficaciaComo un cliente del bancoQuiero transferir fondos entre mis cuentas

Escenario: Transfiriendo dinero a una cuenta de ahorrosDado que mi cuenta Corriente tiene un balance de 1000.00Y que mi cuenta Ahorro tiene un balance de 2000.00Cuando transfiero 500.00 de mi cuenta Corriente a mi cuenta AhorroEntonces debo tener 500.00 en mi cuenta CorrienteY debo tener 2500.00 en mi cuenta Ahorro

Escenario: Transfiriendo con fondos insuficientesDado que mi cuenta Corriente tiene un balance de 1000.00Y que mi cuenta Ahorro tiene un balance de 2000.00Cuando transfiero 1500.00 de mi cuenta Corriente a mi cuenta AhorroEntonces debo recibir un aviso de ‘fondos insuficientes'Y debo tener 1000.00 en mi cuenta CorrienteY debo tener 2000.00 en mi cuenta Ahorro

Escenario: Transfiriendo todo el dineroDado que mi cuenta Corriente tiene un balance de 1000.00Y que mi cuenta Ahorro tiene un balance de 2000.00Cuando transfiero 1000.00 de mi cuenta Corriente a mi cuenta AhorroEntonces debo tener 0.00 en mi cuenta CorrienteY debo tener 3000.00 en mi cuenta AhorroY 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.

Tecnologías para BDD

Implementando BDD: Automatizando escenariosEscenario: Transfiriendo dinero a una cuenta de ahorros

Dado que mi cuenta Corriente tiene un balance de 1000.00Y que mi cuenta Ahorro tiene un balance de 2000.00Cuando transfiero 500.00 de mi cuenta Corriente a mi cuenta AhorroEntonces debo tener 500.00 en mi cuenta CorrienteY debo tener 2500.00 en mi cuenta Ahorro

Implementando BDD: Automatizando escenariosEscenario: Transfiriendo dinero a una cuenta de ahorros

Dado que mi cuenta Corriente tiene un balance de 1000.00Y que mi cuenta Ahorro tiene un balance de 2000.00Cuando transfiero 500.00 de mi cuenta Corriente a mi cuenta AhorroEntonces debo tener 500.00 en mi cuenta CorrienteY 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}

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

BDD a nivel UI: Vital el diseño por capasCapa de Reglas de Negocio

Escenario: Añadir nuevo recordatorio de vacunaDado que necesitamos planificar la siguiente vacunación:

| usuario | vacuna | fecha | centro || Manuel Rodríguez | Rubeola | 24/08/2017 | La Paz |

Cuando creamos un nuevo recordatorio de vacunaEntonces el recordatorio se añade correctamente en la pantalla

BDD a nivel UI: Vital el diseño por capas

Capa de Flujo de Negocio

Capa de Reglas 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);

}

BDD a nivel UI: Vital el diseño por capas

Capa de Implementación Técnica

Capa de Flujo de Negocio

Capa de Reglas 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 BRONCEDado que Ana López no es clienta de nuestro supermercadoCuando 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





@Testpublic 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);

}}

@Testpublic 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?

Cas 2017 bdd-colaborando_de_verdad_con_negocio

Software

Transcript of Cas 2017 bdd-colaborando_de_verdad_con_negocio