Especificación por ejemplo
| Parte de una serie sobre |
| Desarrollo de software |
|---|
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).
Ventajas
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]
Los ejemplos como fuente única de verdad
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]
Prácticas clave
Los equipos que aplican la Especificación mediante el ejemplo con éxito suelen aplicar los siguientes patrones de proceso: [1]
- Derivación del alcance a partir de los objetivos
- Especificación colaborativa: a través de talleres de especificación de todo el equipo, reuniones más pequeñas o revisiones por teleconferencia
- Ilustrar los requisitos mediante ejemplos
- Especificaciones de refinación
- Automatizar pruebas basadas en ejemplos
- Validar el software subyacente con frecuencia mediante pruebas
- Desarrollar un sistema de documentación a partir de especificaciones con ejemplos para respaldar el desarrollo futuro
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]
Ejemplo de mapeo
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]
Aplicabilidad
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).
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 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.
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 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:
- ¡Tenga cuidado!
- Concordia
- Pepino
- FitNesse
- Marco para pruebas integradas
- Marco de trabajo del robot
- SpecFlow para .NET
- Calibre (software)
Referencias
- ^ abcde Adzic, Gojko (2011). Especificación mediante ejemplos: 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 mediante la colaboración: una historia de desarrollo basado en pruebas de aceptación Lean-Agile . Addison Wesley. ISBN 978-0-321-71408-4.
- ^ abc Larman, Craig; Vodde, Bas (2010). Prácticas para escalar el desarrollo ágil y esbelto: desarrollo de productos a gran escala, en múltiples sitios y en el extranjero con Scrum a gran escala. Pearson. ISBN 978-0-321-63640-9.
- ^ ab Adzic, Gojko (2009). Salvando la brecha de comunicación: especificación mediante ejemplos y pruebas de aceptación ágiles . Neuri. ISBN 0-9556836-1-0.
- ^ Wynne, Matt (8 de diciembre de 2015). "Introducción a la asignación de ejemplos". Blog de Cucumber . Consultado el 10 de mayo de 2021 .
- ^ Crispin, Lisa; Gregory, Janet (2008). Pruebas ágiles: una guía práctica para evaluadores 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 de patrones 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 .
{{cite web}}: CS1 maint: numeric names: authors list (link) - ^ 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: cómo abordar la complejidad en el corazón del software . Addison-Wesley. ISBN 0-321-12521-5.
- ^ Weinberg, Gerald ; Gause, Donald (1989). Explorando los requisitos: la calidad antes que el diseño. Dorset House. ISBN 0-932633-13-7.
Enlaces externos
- Grupo de discusión de Google
- Libros, vídeos, herramientas y presentaciones de Specificationbyexample.com
- Definición de bliki de Martin Fowler
