La especificación por ejemplo ( SBE ) es un enfoque colaborativo para definir requisitos y pruebas funcionales orientadas al negocio para productos de software basado en capturar e ilustrar requisitos utilizando ejemplos realistas en lugar de declaraciones abstractas. Se aplica en el contexto de métodos ágiles de desarrollo de software , en particular el desarrollo basado en el comportamiento . Este enfoque es particularmente exitoso para gestionar requisitos y pruebas funcionales en proyectos a gran escala de gran complejidad organizacional y de dominio. [1]
La especificación por ejemplo también se conoce como desarrollo basado en ejemplos, requisitos ejecutables, desarrollo basado en pruebas de aceptación (ATDD [2] o A-TDD [3] ), pruebas de aceptación ágiles, [4] requisitos basados en pruebas (TDR).
Los conceptos nuevos muy abstractos o novedosos pueden resultar difíciles de entender sin ejemplos concretos. [ cita necesaria ] La especificación mediante ejemplo tiene como objetivo construir una comprensión precisa y reduce significativamente los ciclos de retroalimentación en el desarrollo de software, lo que lleva a menos retrabajo, mayor calidad del producto, tiempo de respuesta más rápido para los cambios de software y una mejor alineación de las actividades de los diversos roles involucrados en el software. desarrollo como testers, analistas y desarrolladores. [1]
Un aspecto clave de la especificación mediante el ejemplo es crear una única fuente de verdad sobre los cambios necesarios desde todas las perspectivas. Cuando los analistas de negocios trabajan en sus propios documentos, los desarrolladores de software mantienen su propia documentación y los evaluadores mantienen un conjunto separado de pruebas funcionales, la efectividad de la entrega de software se reduce significativamente por la necesidad de coordinar y sincronizar constantemente esas diferentes versiones de la verdad. Con ciclos iterativos cortos, dicha coordinación suele ser necesaria semanal o quincenalmente. Con la Especificación por ejemplo, diferentes roles participan en la creación de una única fuente de verdad que capta la comprensión de todos. Se utilizan ejemplos para proporcionar claridad y precisión, de modo que la misma información pueda usarse como especificación y como prueba funcional orientada al negocio. Cualquier información adicional descubierta durante el desarrollo o la entrega, como la aclaración de brechas funcionales, requisitos faltantes o incompletos o pruebas adicionales, se agrega a esta única fuente de verdad. Como solo existe una fuente de verdad sobre la funcionalidad, no hay necesidad de coordinación, traducción e interpretación del conocimiento dentro del ciclo de entrega.
Cuando se aplica a los cambios requeridos, un conjunto refinado de ejemplos es efectivamente una especificación y una prueba orientada al negocio para la aceptación de la funcionalidad del software. Una vez implementado el cambio, la especificación con ejemplos se convierte en un documento que explica la funcionalidad existente. Como la validación de dichos documentos está automatizada, cuando se validan con frecuencia, dichos documentos son una fuente confiable de información sobre la funcionalidad comercial del software subyacente. Para distinguir entre este tipo de documentos y la documentación impresa típica, que rápidamente queda obsoleta, [4] un conjunto completo de especificaciones con ejemplos se denomina Living Documentation. [1]
Los equipos que aplican la Especificación por ejemplo con éxito suelen aplicar los siguientes patrones de proceso: [1]
Los equipos de software que aplican especificaciones mediante ejemplos dentro de un marco Scrum normalmente dedican entre el 5 % y el 10 % de su tiempo a perfeccionar el trabajo pendiente del producto, incluida la especificación colaborativa, la ilustración de requisitos mediante ejemplos y el perfeccionamiento de ejemplos. [3]
El mapeo de ejemplo es una técnica simple que puede dirigir la conversación y derivar criterios de aceptación en poco tiempo. El proceso divide las historias en reglas y ejemplos documentados en forma de especificación por ejemplo, y es una técnica ampliamente utilizada en el ámbito de BDD. [5]
La especificación mediante ejemplo se aplica a proyectos con suficiente complejidad organizacional y de dominio como para causar problemas en la comprensión o comunicación de los requisitos desde una perspectiva de dominio empresarial. No se aplica a problemas puramente técnicos o donde la complejidad clave no está en comprender o comunicar conocimientos. Hay usos documentados de este enfoque en ámbitos que incluyen banca de inversión, comercio financiero, seguros, reserva de billetes de avión, juegos en línea y comparación de precios. [1] Un enfoque similar está documentado también en un proyecto de simulación de una central nuclear. [3]
Las pruebas basadas en ejemplos compartidos encajan mejor en la categoría de pruebas diseñadas para respaldar a un equipo mientras se entrega software desde una perspectiva empresarial (consulte Cuadrantes de pruebas ágiles [6] ), lo que garantiza que se cree el producto correcto. No reemplazan las pruebas que analizan un sistema de software desde una perspectiva puramente técnica (aquellas que evalúan si un producto está construido de la manera correcta, como pruebas unitarias, de componentes o de integración técnica) o pruebas que evalúan un producto después de su desarrollo. (como pruebas de penetración de seguridad).
El primer uso documentado de ejemplos realistas como fuente única de verdad, requisitos y pruebas automatizadas en proyectos de software es el proyecto WyCash+, descrito por Ward Cunningham en el artículo A Pattern Language of Competitive Development [7] [8] en 1996. El nombre Especificación por ejemplo fue acuñado por Martin Fowler en 2004. [9]
La especificación por ejemplo es una evolución de la práctica de Prueba de cliente [10] de Programación extrema propuesta alrededor de 1997 y la idea del Lenguaje ubicuo [11] del diseño impulsado por dominios de 2004, utilizando la idea de pruebas de caja negra como requisitos descritos por Weinberg y Gause. [12] en 1989.
La aplicación exitosa de la Especificación mediante ejemplo en proyectos a gran escala requiere una validación frecuente de la funcionalidad del software frente a un gran conjunto de ejemplos (pruebas). En la práctica, esto requiere que se automaticen pruebas basadas en ejemplos. Un enfoque común es automatizar las pruebas pero mantener los ejemplos en una forma legible y accesible para los miembros del equipo técnicos y no técnicos, manteniendo los ejemplos como una única fuente de verdad. Este proceso está respaldado por una clase de herramientas de automatización de pruebas que trabajan con pruebas divididas en dos aspectos: la especificación y la capa de automatización. La especificación de una prueba que suele estar en texto plano o HTML y contiene ejemplos y descripciones auxiliares. La capa de automatización conecta el ejemplo a un sistema de software bajo prueba. Ejemplos de tales herramientas son:
{{cite web}}: CS1 maint: numeric names: authors list (link)