Meetup bdd & tdd: aprovecha_su_poder
- 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
- 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