no es una herramienta de prueba, es una herramienta BDD para la colaboración entre todos los miembros del equipo. Entonces, si está utilizando Cucumber.io solo para pruebas automatizadas, puede hacerlo mejor. Testwise Cucumber es un marco que entiende a Gherkin y ejecuta las pruebas automatizadas. Suena como un cuento de hadas, obtienes tu documentación descrita en Gherkin y las pruebas simplemente se ejecutan. En realidad, no es tan simple, cada paso de la documentación debe tener un código de prueba subyacente que manipule la aplicación y debe tener condiciones de prueba. Todo el proceso se describirá en detalle con ejemplos de código y con detalles de sus funciones.BDD es un método cuidadosamente desarrollado manteniendo los principios del Manifiesto Ágil en mente.
Origen de BDD y Cucumber
A principios de la década de 2000, había una pequeña camarilla de personas de la comunidad XP que estaban explorando mejores formas de hacer TDD (Test Driven Development). Dan North llamó a este BDD (Behavior Driven Development). Ahora se lo considera el padre de BDD .
En 2008, se creó Cucumber y actualmente es una de las herramientas BDD más populares disponibles en el mercado. Los creadores de Cucumber ( Aslak Hellesøy y su equipo) idearon proporcionar un lenguaje , un proceso y una herramienta que proporcionaría una única fuente de verdad sobre el comportamiento del software para la audiencia de los miembros del proyecto no técnicos y técnicos . Es necesario seguir los principios de BDD para obtener el máximo rendimiento de Cucumber, porque Cucumber es solo un habilitador para BDD .
La idea era combinar pruebas de aceptación automatizadas, requerimientos funcionales y documentación de software en un formato que sería comprensible para personas no técnicas y herramientas de prueba.
Desarrollo Conducido por el Comportamiento (BDD)
En entornos Ágiles, el Desarrollo Conducido por el Comportamiento (BDD) juega un papel vital porque fomenta el uso de metodologías Ágiles durante el desarrollo y las pruebas. BDD reúne a los clientes, usuarios finales, BA, QA y SE del producto de software en una sola tabla para compartir eficazmente los conocimientos sobre el sistema y sus requisitos de prueba.
Roles y encargados
Las personas a cargo de definir los requisitos (analistas de negocios / propietarios de productos ágiles) se sientan con programadores y probadores y discuten características ( similares a las historias ágiles) que se implementarán.
- La persona de negocios especifica los comportamientos que quiere ver en el sistema.
- El desarrollador hace preguntas basadas en su comprensión del sistema, al tiempo que escribe comportamientos adicionales necesarios desde una perspectiva de desarrollo.
- Los evaluadores, auditores, y tester deciden en qué comportamientos del sistema se escribirán las pruebas de aceptación.
Estos tres encargados (personas de negocios, desarrolladores, probadores) presentan ejemplos de cómo debe comportarse el software y los escriben como Características y escenarios de pepino . A partir de entonces, el desarrollo del software se realiza siguiendo los principios de ATDD (Desarrollo impulsado por pruebas de aceptación ) y TDD (Desarrollo guiado por pruebas ).
Mitos sobre el BDD de Cucumber
Hay personas que han entendido mal este concepto de las características de BDD y Cucumber. Algunos de ellos usan Cucumber como herramienta de prueba y BDD como método de prueba. Algunos escriben características de Cucumber después del desarrollo de su producto de software para reflejar su comportamiento. Aunque todos tienen la libertad de usar estas herramientas como lo deseen, a esta multitud le falta el propósito más importante de esta herramienta de colaboración, creando una comprensión compartida entre tres encargados al discutir ejemplos sobre el producto de software esperado .
Cucumber es ante todo una herramienta de colaboración que tiene como objetivo brindar una comprensión común a los equipos de software, en todos los roles.
Por lo tanto, debe tenerse en cuenta que las herramientas BDD como Cucumber están diseñadas para impulsar el ciclo de vida completo de software de manera más colaborativa.
Las características de Cucumber deberían impulsar la implementación, no reflejarla.
Cucumber no es una herramienta para probar software. Es una herramienta para probar la comprensión de las personas sobre cómo debe comportarse el software (aún por escribir).
La mayor ventaja del enfoque BDD para el desarrollo de software podría ser que describen un conjunto de funciones que un usuario espera de un sistema de una manera muy concreta y directa.
La suma de estos comportamientos esencialmente documenta un contrato con el usuario / cliente. Si alguna de las pruebas falla, este contrato no se confirma.
Simulemos BDD
A los millennials les encanta construir cosas que leer documentos. Así que simulemos las etapas de BDD de una manera de muy alto nivel y creemos un proyecto ficticio con Cucumber BDD para comprender el flujo de trabajo. Tenga en cuenta que esto es solo para su comprensión.
Supongamos que nuestro producto es un software de gestión de recursos humanos basado en la web y que discutiremos las características de inicio de sesión de perfil y actualización con especificación por método de ejemplo
Escribir especificaciones ejecutables con ejemplos
Esta es la etapa más importante de BDD. Tres amigos (personas de negocios, desarrolladores, evaluadores) se reúnen e identifican el comportamiento esperado de nuestro producto discutiendo ejemplos. Podemos utilizar el enfoque de mapeo de características para analizar y elaborar de manera efectiva el comportamiento del producto.
Mapeo de características
El mapeo de características es una práctica colaborativa simple diseñada por John Ferguson Smart para ayudar a los equipos a escribir excelentes especificaciones ejecutables. El mapeo de características se basa en el mapeo de historias de Jeff Patton, el mapeo de ejemplos de Matt Wynne y otras técnicas.
En pocas palabras, el proceso es algo como esto:
- Defina una característica o historia, o elija una de la cartera de pedidos.
- Comprende qué actores están involucrados en la historia.
- Divida la función en tareas para identificar los flujos principales.
- Identifique ejemplos que ilustren un principio o flujo variante. Haga preguntas como: "Pero, ¿y si ..."; "Qué más podría conducir a este resultado"; "Qué otros resultados podrían suceder"; y usa las respuestas para crear nuevos ejemplos. Use reglas para explicar y dar contexto a sus ejemplos .
- Enjuague y repita para otras reglas y ejemplos.
- Cree especificaciones ejecutables : automatice los principales flujos de alto nivel con pasos pendientes.
Supongamos que las discusiones de nuestros tres encargados están sucediendo ahora. Escriben el resultado de sus discusiones como características y escenarios de alto nivel en una gramática legible para los negocios. Si está familiarizado con ágil, este proceso es muy similar a la conocida escritura de historias ágiles. Las siguientes son las características que discutimos. Tenga en cuenta que son de muy alto nivel y abstractos .
Característica: Perfil de inicio de sesión
Actor: Como empleado de la empresa
escenarios:Quiero iniciar sesión en mi perfil de empleado usando mis credenciales
escenarios: Para colaborar con mis colegas
Característica: Actualizar perfil
Actor: Como empleado de la empresa
escenarios: Quiero poder actualizar mi nombre, proyectos, correo electrónico y números de teléfono en mi perfil
escenarios: Para compartir mi información de contacto con mis colegas
En nuestro caso, observe que solo hay un actor : el empleado.
Ahora estamos listos para dividir la función en tareas y escenarios .
Característica:
Escenario del perfil de inicio de sesión : Escenario de inicio de sesión exitoso.
Escenario del perfil de inicio de sesión :Inicio de sesión fallido con credenciales incorrectas
Característica:
Escenario del perfil de actualización : Nombre de la actualización
Escenario: Agregar nuevos proyectos
Para ejecutar escenarios, necesitamos establecer los pasos y las reglas involucradas en cada escenario. Por ejemplo, consideremos un escenario de inicio de sesión exitoso .
Antes de iniciar sesión en el perfil, el empleado primero debe visitar la página de inicio de la empresa. Esta es una condición previa, es decir, un escenario de fondo que ayuda a realizar con éxito nuestro escenario esperado, un inicio de sesión exitoso . Así que identifiquemos sus pasos.
Antecedentes: el usuario navega a la página de inicio de la empresa
Pasos: 1) Ir a la página de inicio de la empresa
2) Ver la opción de inicio de sesión (esto es consecuencia del paso anterior)
Escenario: inicio de sesión exitoso
Pasos: 1) Ingrese las credenciales correctas
2) Inicie sesión en la cuenta
3) Vea mensaje de bienvenida (esto es consecuencia del paso anterior)
Ahora viene una parte difícil, la realización de las características y escenarios anteriores. Necesitamos obtener las aportaciones de los desarrolladores y evaluadores y convertir los escenarios anteriores de la historia en pasos ejecutables en el formato Given / When / Then del lenguaje Gherkin. Además, debe tenerse en cuenta que las personas de negocios deben estar de acuerdo con estos pasos.
Antecedentes: el usuario navega a la página de inicio de la empresa
Dado que estoy en la página "Página de inicio de la empresa " en la URL " www.anezsoft.com "
Entonces debería ver el mensaje " Iniciar sesión como empleado "
Escenario: Inicio de sesión exitoso
cuando complete " Nombre de usuario " con " Probar "
Y rellenar " Contraseña " con " 123 "
Y hacer clic en el botón " Iniciar sesión "
Luego estoy en la página " Mi perfil " en la URL " www.anezsoft.com/miperfil" YDebería ver el mensaje " Bienvenido a tu perfil "
y debería ver el botón " Cerrar sesión "
NOTA : El escenario anterior está escrito para servir como un ejemplo simple y no es el mejor enfoque para escribir escenarios. En producción, siempre asegúrese de que sus escenarios no estén estrechamente vinculados con sus pruebas. Sus escenarios de BDD deberían cambiar solo cuando los requisitos cambien, no cuando cambie la implementación (es decir,sus escenarios de BDD deben impulsar la implementación, no al revés).
Del mismo modo, uno puede analizar todas las características, describir el comportamiento utilizando ejemplos, reglas, consecuencias y escribirlas en formato Gherkin con el acuerdo mutuo y la comprensión entre personas de negocios, desarrolladores y evaluadores. Puede ver estas realizaciones en los archivos LoginProfile.feature y UpdateProfile.feature en la sección a continuación.
Comentarios