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 la captura e ilustración de requisitos mediante ejemplos realistas en lugar de declaraciones abstractas. Se aplica en el contexto de métodos de desarrollo de software ágiles , en particular el desarrollo impulsado por el comportamiento . Este enfoque es particularmente exitoso para gestionar requisitos y pruebas funcionales en proyectos a gran escala de una complejidad organizacional y de dominio significativa. [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 altamente abstractos o novedosos pueden ser difíciles de entender sin ejemplos concretos. [ cita requerida ] La especificación mediante ejemplos 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 reelaboración, mayor calidad del producto, tiempos de respuesta más rápidos para los cambios de software y una mejor alineación de las actividades de varios roles involucrados en el desarrollo de software, como probadores, analistas y desarrolladores. [1]
Un aspecto clave de la especificación por ejemplo es la creación de una única fuente de información 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 eficacia 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 requerirse semanal o quincenalmente. Con la especificación por ejemplo, diferentes roles participan en la creación de una única fuente de información que captura la comprensión de todos. Los ejemplos se utilizan para proporcionar claridad y precisión, de modo que la misma información se pueda utilizar tanto como una especificación como una prueba funcional orientada al negocio. Cualquier información adicional que se descubra 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 información. Como solo hay una fuente de información sobre la funcionalidad, no hay necesidad de coordinación, traducción e interpretación de conocimientos dentro del ciclo de entrega.
Cuando se aplica a los cambios necesarios, un conjunto refinado de ejemplos es efectivamente una especificación y una prueba orientada a la empresa 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, estos documentos son una fuente confiable de información sobre la funcionalidad empresarial del software subyacente. Para distinguir entre estos documentos y la documentación impresa típica, que rápidamente se vuelve obsoleta, [4] un conjunto completo de especificaciones con ejemplos se denomina Documentación Viva. [1]
Los equipos que aplican la Especificación mediante el 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 generalmente dedican entre el 5% y el 10% de su tiempo a refinar el backlog del producto, lo que incluye especificar de manera colaborativa, ilustrar requisitos mediante ejemplos y refinar ejemplos. [3]
El mapeo de ejemplos es una técnica sencilla que puede guiar 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 mediante ejemplos, y es una técnica ampliamente utilizada en el ámbito de BDD. [5]
La especificación por ejemplo se aplica a proyectos con una complejidad organizativa y de dominio suficiente 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 en los que la complejidad clave no está en la comprensión o comunicación de los conocimientos. Existen usos documentados de este enfoque en ámbitos como la banca de inversión, el comercio financiero, los seguros, la reserva de billetes de avión, los juegos en línea y la comparación de precios. [1] También se documenta un enfoque similar en un proyecto de simulación de una planta de energía nuclear. [3]
Las pruebas basadas en ejemplos compartidos encajan mejor en la categoría de pruebas diseñadas para respaldar a un equipo mientras entrega software desde una perspectiva comercial (consulte los Cuadrantes de pruebas ágiles [6] ), lo que garantiza que se construya 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, pruebas 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 pruebas de clientes [10] de programación extrema propuesta alrededor de 1997 y de la idea de lenguaje ubicuo [11] del diseño impulsado por el dominio 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 por 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 las pruebas basadas en ejemplos se automaticen. Un enfoque común es automatizar las pruebas, pero mantener los ejemplos en un formato 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 a menudo se presenta en formato de texto simple o HTML, contiene los ejemplos y las descripciones auxiliares. La capa de automatización conecta el ejemplo a un sistema de software bajo prueba. Algunos ejemplos de dichas herramientas son:
{{cite web}}: CS1 maint: numeric names: authors list (link)