La especificación por ejemplo ( SBE ) es un enfoque colaborativo para definir requisitos y pruebas funcionales orientadas al negocio para productos de software que se basan 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 impulsado por el comportamiento . Este enfoque es particularmente exitoso para administrar requisitos y pruebas funcionales en proyectos a gran escala de dominio significativo y complejidad organizacional. [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 ágil, [4] requisitos basados en pruebas (TDR).
Ventajas
Los conceptos nuevos muy abstractos o novedosos pueden ser difíciles de entender sin ejemplos concretos. [ cita requerida ] La especificación por ejemplo tiene la intención de 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, tiempo de respuesta más rápido para los cambios de software y mejor alineación de las actividades de varios roles involucrados en el software desarrollo como probadores, analistas y desarrolladores. [1]
Ejemplos como fuente única de verdad
Un aspecto clave de la especificación mediante el ejemplo es la creación de 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 a menudo se requiere semanalmente o quincenalmente. Con Specification by example, diferentes roles participan en la creación de una única fuente de verdad 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 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 hay 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 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]
Prácticas clave
Los equipos que aplican la Especificación por ejemplo con éxito suelen aplicar los siguientes patrones de proceso: [1]
- Derivando el alcance de los objetivos
- Especificar en colaboración: a través de talleres de especificaciones para todo el equipo, reuniones más pequeñas o revisiones por teleconferencia
- Ilustrando requisitos usando ejemplos
- Refinando especificaciones
- Automatización de pruebas basadas en ejemplos
- Validar el software subyacente con frecuencia utilizando las pruebas
- Evolución de un sistema de documentación a partir de especificaciones con ejemplos para respaldar el desarrollo futuro
Los equipos de software que aplican la especificación por ejemplo dentro de un marco de Scrum suelen dedicar entre un 5% y un 10% de su tiempo a refinar la cartera de productos, incluida la especificación en colaboración, la ilustración de los requisitos mediante ejemplos y el refinamiento de ejemplos. [3]
Mapeo de ejemplo
El mapeo de ejemplos es una técnica simple que puede dirigir la conversación y derivar criterios de aceptación en poco tiempo. El proceso divide historias en Reglas y Ejemplos documentados en forma de especificación por ejemplo, y es una técnica ampliamente utilizada en la esfera de BDD. [5]
Aplicabilidad
La especificación por ejemplo se aplica a proyectos con suficiente complejidad organizativa y de dominio 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 dominios que incluyen banca de inversión, comercio financiero, seguros, reserva de boletos de avión, juegos en línea y comparación de precios. [1] También se documenta un enfoque similar 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 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 integración técnica o de componentes) o pruebas que evalúan un producto después de su desarrollo. (como pruebas de penetración de seguridad).
Historia
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 El nombre Specification by Example fue acuñado por Martin Fowler en 2004. [9]
La especificación por ejemplo es una evolución de la práctica de Customer Test [10] de Extreme Programming propuesta alrededor de 1997 y la idea de Ubiquitous Language [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.
Automatización
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 la automatización de 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 no 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 funcionan 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 encuentra en texto sin formato o en formato HTML y contiene los ejemplos y descripciones auxiliares. La capa de automatización conecta el ejemplo a un sistema de software bajo prueba. Ejemplos de tales herramientas son:
Referencias
- ↑ a b c d e Adzic, Gojko (2011). Especificación por ejemplo: cómo los equipos exitosos entregan el software adecuado . Manning. ISBN 9781617290084.
- ^ Pugh, Ken (2011). Desarrollo basado en pruebas de aceptación Lean-Agile: mejor software a través de la colaboración: una historia de desarrollo basado en pruebas de aceptación Lean-Agile . Addison Wesley. ISBN 978-0-321-71408-4.
- ^ a b c Larman, Craig; Vodde, Bas (2010). Prácticas para escalar el desarrollo ágil y esbelto: desarrollo de productos grandes, multisitio y offshore con Scrum a gran escala . Pearson. ISBN 978-0-321-63640-9.
- ^ a b Adzic, Gojko (2009). Superando la brecha de comunicación: especificación por ejemplo y pruebas de aceptación ágiles . Neuri. ISBN 0-9556836-1-0.
- ^ Wynne, Matt (8 de diciembre de 2015). "Presentación de mapeo de ejemplo" . Blog de pepino . Consultado el 10 de mayo de 2021 .
- ^ Crispin, Lisa ; Gregory, Janet (2008). Pruebas ágiles: una guía práctica para probadores y equipos ágiles . Addison Wesley. ISBN 978-0-321-53446-0.
- ^ Lenguajes de patrones de diseño de programas 2 . Addison-Wesley. 1996. ISBN 978-0-201-89527-8.
- ^ Ward Cunningham. "EPISODIOS: un lenguaje patrón de desarrollo competitivo parte I" . C2.com . Consultado el 8 de enero de 2014 .
- ^ Martin Fowler 18 de marzo de 2004 (18 de marzo de 2004). "SpecificationByExample" . Martinfowler.com . Consultado el 8 de enero de 2014 .
- ^ Beck, K. (1999). Explicación de la programación extrema: Acepte el cambio . Addison-Wesley. ISBN 978-0-321-27865-4.
- ^ Evans, Eric (2004). Diseño basado en dominios: abordar la complejidad en el corazón del software . Addison-Wesley. ISBN 0-321-12521-5.
- ^ Weinberg, Gerald ; Gause, Donald (1989). Explorando los requisitos: calidad antes que diseño . Casa Dorset. ISBN 0-932633-13-7.
enlaces externos
- Grupo de discusión de Google
- Libros, videos, herramientas y presentaciones de Specificationbyexample.com
- Definición de bliki de Martin Fowler