BDD - Especificaciones por ejemplo
Según Gojko Adzic, autor de 'Specification by Example', Specification by Example es un conjunto de patrones de proceso que facilitan el cambio en los productos de software para garantizar que el producto correcto se entregue de manera eficiente ".
La especificación por ejemplo es un enfoque colaborativo para definir los requisitos y las pruebas funcionales orientadas al negocio para productos de software basados en capturar e ilustrar requisitos utilizando ejemplos realistas en lugar de declaraciones abstractas.
Especificación por ejemplo: descripción general
El objetivo de Especificación por ejemplo es centrarse en el desarrollo y la entrega de requisitos comerciales priorizados y verificables. Si bien el concepto de Especificación por ejemplo en sí mismo es relativamente nuevo, es simplemente una reformulación de las prácticas existentes.
Es compatible con un vocabulario muy específico y conciso conocido como lenguaje ubicuo que:
Habilita los requisitos ejecutables.
Es utilizado por todos en el equipo.
Es creado por un equipo multifuncional.
Captura la comprensión de todos.
La especificación por ejemplo se puede utilizar como entrada directa en la creación de pruebas automatizadas que reflejen el dominio empresarial. Por lo tanto, el enfoque de Especificación por ejemplo es construir el producto correcto y construir el producto correctamente.
Propósito de la especificación por ejemplo
El objetivo principal de Specification by Example es construir el producto correcto. Se centra en la comprensión compartida, estableciendo así una única fuente de verdad. Permite la automatización de los criterios de aceptación para que el enfoque esté en la prevención de defectos en lugar de la detección de defectos. También promueve la prueba temprana para encontrar los defectos temprano.
Uso de SbE
La especificación por ejemplo se utiliza para ilustrar el comportamiento esperado del sistema que describe el valor comercial. La ilustración es mediante ejemplos concretos y de la vida real. Estos ejemplos se utilizan para crear requisitos ejecutables que son:
Comprobable sin traducción.
Capturado en documentación en vivo.
Las siguientes son las razones por las que usamos ejemplos para describir especificaciones particulares:
Son más fáciles de entender.
Son más difíciles de malinterpretar.
Ventajas de SbE
Las ventajas de usar Especificación por ejemplo son:
Mayor calidad
Reducción de residuos
Riesgo reducido de defectos de producción
Esfuerzo concentrado
Los cambios se pueden realizar de forma más segura
Mayor participación empresarial
Aplicaciones de SbE
Especificación por ejemplo buscar aplicaciones en -
Ya sea una empresa compleja o una organización compleja.
No funciona bien para problemas puramente técnicos.
No funciona bien para productos de software centrados en la interfaz de usuario.
También se puede aplicar a sistemas heredados.
Pruebas de aceptación y SbE
Las ventajas de la especificación por ejemplo en términos de pruebas de aceptación son:
Se utiliza una única ilustración tanto para los requisitos detallados como para las pruebas
El progreso del proyecto está en términos de pruebas de aceptación -
Cada prueba es para probar un comportamiento.
Una prueba está pasando por un comportamiento o no.
Una prueba aprobatoria representa que se completa el comportamiento particular.
Si un proyecto que requiere que se completen 100 comportamientos tiene 60 comportamientos completados, entonces está terminado en un 60%.
Los probadores pasan de la reparación de defectos a la prevención de defectos y contribuyen al diseño de la solución.
La automatización permite una comprensión instantánea del impacto de un cambio de requisitos en la solución.
Especificación por ejemplo: lo que significa para diferentes roles
El objetivo de Especificación por ejemplo es promover la colaboración de todos en el equipo, incluido el cliente durante todo el proyecto para ofrecer valor comercial. Todos, para una mejor comprensión, utilizan el mismo vocabulario.
| Papel | Uso de SbE |
|---|---|
| Analista de negocios |
|
| Desarrollador |
|
| Ensayador |
|
| Todos |
|
SbE: un conjunto de patrones de proceso
Como hemos visto al comienzo de este capítulo, la especificación por ejemplo se define como un conjunto de patrones de proceso que facilitan el cambio en los productos de software para garantizar que el producto correcto se entregue de manera eficiente.
Los patrones de proceso son:
Especificación colaborativa
Ilustrando especificaciones usando ejemplos
Refinando la especificación
Ejemplos de automatización
Validando frecuentemente
Documentación viva
Especificación colaborativa
Los objetivos de la especificación colaborativa son:
Obtenga los distintos roles en un equipo para tener un entendimiento común y un vocabulario compartido.
Haga que todos se involucren en el proyecto para que puedan contribuir con sus diferentes perspectivas sobre una característica.
Garantice la comunicación compartida y la propiedad de las funciones.
Estos objetivos se cumplen en un taller de especificaciones también conocido como la reunión de los Tres Amigos. Los Tres Amigos son BA, QA y el desarrollador. Aunque hay otros roles en el proyecto, estos tres serían responsables desde la definición hasta la entrega de las características.
During the meeting −
El analista de negocios (BA) presenta los requisitos y pruebas para una nueva característica.
Los tres Amigos (BA, Desarrollador y QA) discuten la nueva característica y revisan las especificaciones.
El QA y el desarrollador también identifican los requisitos que faltan.
Los tres amigos
Utilice un modelo compartido con un lenguaje ubicuo.
Utilice vocabulario de dominio (se mantiene un glosario si es necesario).
Busque diferencias y conflictos.
No salte a los detalles de implementación en este momento.
Llegue a un consenso sobre si una característica se especificó suficientemente.
Un sentido compartido de los requisitos y la propiedad de la prueba facilita las especificaciones de calidad
Los requisitos se presentan como escenarios, que proporcionan requisitos explícitos e inequívocos. Un escenario es un ejemplo del comportamiento del sistema desde la perspectiva de los usuarios.
Ilustrando la especificación usando ejemplos
Los escenarios se especifican utilizando la estructura Given-When-Then para crear una especificación comprobable:
Given <alguna condición previa>
And <condiciones previas adicionales> Optional
When <ocurre una acción / desencadenante>
Then <alguna condición de publicación>
And <condiciones de publicación adicionales> Optional
Esta especificación es un ejemplo de comportamiento del sistema. También representa un criterio de aceptación del sistema.
El equipo analiza los ejemplos y la retroalimentación se incorpora hasta que hay un acuerdo de que los ejemplos cubren el comportamiento esperado de la función. Esto asegura una buena cobertura de prueba.
Refinando la especificación
Para refinar una especificación,
Sea preciso al escribir los ejemplos. Si un ejemplo se vuelve complejo, divídalo en ejemplos más simples.
Concéntrese en la perspectiva empresarial y evite los detalles técnicos.
Considere las condiciones tanto positivas como negativas.
Adhiérase al vocabulario específico del dominio.
Analice los ejemplos con el cliente.
Elija conversaciones para lograr esto.
Considere solo los ejemplos que le interesan al cliente. Esto permite la producción del código requerido únicamente y evita cubrir todas las combinaciones posibles, que pueden no ser necesarias.
Para asegurarse de que el escenario pasa, todos los casos de prueba para ese escenario deben pasar. Por lo tanto, mejore las especificaciones para hacerlas comprobables. Los casos de prueba pueden incluir varios rangos y valores de datos (casos de límite y esquina), así como diferentes reglas comerciales que dan como resultado cambios en los datos.
Especifique reglas comerciales adicionales, como cálculos complejos, manipulación / transformación de datos, etc.
Incluya escenarios no funcionales (por ejemplo, rendimiento, carga, usabilidad, etc.) como Especificación por ejemplo
Ejemplos de automatización
La capa de automatización debe mantenerse muy simple, simplemente cableando la especificación al sistema bajo prueba. Puedes usar una herramienta para lo mismo.
Realice la automatización de pruebas utilizando el lenguaje específico del dominio (DSL) y muestre una conexión clara entre las entradas y las salidas. Céntrese en la especificación y no en el guión. Asegúrese de que las pruebas sean precisas, fáciles de entender y comprobables.
Validar con frecuencia
Incluya una validación de ejemplo en su canal de desarrollo con cada cambio (adición / modificación). Hay muchas técnicas y herramientas que pueden (y deben) adoptarse para ayudar a garantizar la calidad de un producto. Giran en torno a tres principios clave:Test Early, Test Well y Test Often.
Ejecute las pruebas con frecuencia para que pueda identificar los eslabones débiles. Los ejemplos que representan los comportamientos ayudan a rastrear el progreso y se dice que un comportamiento está completo solo después de que pasa la prueba correspondiente.
Documentación viva
Mantenga las especificaciones lo más simples y breves posible. Organice las especificaciones y evolucione a medida que avanza el trabajo. Haga que la documentación sea accesible para todos los miembros del equipo.
Especificación mediante pasos de proceso de ejemplo
La ilustración muestra los pasos del proceso en Especificación por ejemplo.
Anti-patrones
Los anti-patrones son ciertos patrones en el desarrollo de software que se consideran una mala práctica de programación. A diferencia de los patrones de diseño, que son enfoques comunes a problemas comunes, que se han formalizado y generalmente se consideran una buena práctica de desarrollo, los antipatrones son lo opuesto y no son deseables.
Los antipatrones dan lugar a varios problemas.
| Anti-patrón | Problemas |
|---|---|
| Sin colaboración |
|
| Sin darse cuenta cuando el código está terminado |
|
| Ejemplos demasiado detallados o centrados en la interfaz de usuario |
|
| Subestimar el esfuerzo requerido |
|
Solución a los problemas: calidad
La calidad puede garantizarse vigilando los antipatrones. Para minimizar los problemas creados por anti-patrones, debe:
Reúnanse para especificar usando ejemplos.
Limpiar y mejorar los ejemplos.
Escribe un código que satisfaga los ejemplos.
Automatice los ejemplos e impleméntelos.
Repita el enfoque para cada historia de usuario.
Resolver los problemas debidos a anti-patrones significa adherirse a:
Collaboration.
Centrándose en qué.
Centrándose en los negocios.
Estar preparado.
Entendamos lo que significa cada uno de los anteriores.
Colaboración
En colaboración -
Los empresarios, los desarrolladores y los probadores aportan información desde sus propias perspectivas.
Los ejemplos automatizados demuestran que el equipo ha construido lo correcto.
El proceso es más valioso que las pruebas mismas.
Centrándonos en lo que
Debes concentrarte en la pregunta: 'qué'. Mientras se enfoca en 'qué' -
No intente cubrir todos los casos posibles.
No olvide utilizar diferentes tipos de pruebas.
Mantenga los ejemplos lo más simples posible.
Los ejemplos deben ser fácilmente comprensibles para los usuarios del sistema.
Las herramientas no deben jugar un papel importante en los talleres.
Centrándose en los negocios
Para centrarse en el negocio:
Mantenga la especificación según la intención comercial.
Incluya empresas en la creación y revisión de especificaciones.
Ocultar todos los detalles en la capa de automatización.
Estar preparado
Esté preparado para lo siguiente:
Los beneficios no son evidentes de inmediato, incluso cuando se cambian las prácticas del equipo.
Presentar SbE es un desafío.
Requiere tiempo e inversiones.
Las pruebas automatizadas no son gratuitas.
Herramientas
El uso de herramientas no es obligatorio para la especificación por ejemplo, aunque en la práctica hay varias herramientas disponibles. Hay casos que tienen éxito siguiendo la Especificación por ejemplo incluso sin usar una herramienta.
Las siguientes herramientas admiten la especificación por ejemplo:
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog