El desarrollo impulsado por pruebas de aceptación ( ATDD ) es una metodología de desarrollo basada en la comunicación entre los clientes comerciales, los desarrolladores y los evaluadores. [1] ATDD abarca muchas de las mismas prácticas que la especificación por ejemplo (SBE), [2] [3] el desarrollo impulsado por el comportamiento (BDD), [4] el desarrollo impulsado por el ejemplo (EDD), [5] y el apoyo impulsado desarrollo también llamado desarrollo guiado por pruebas de historia (SDD). [6] Todos estos procesos ayudan a los desarrolladores y evaluadores a comprender las necesidades del cliente antes de la implementación y permiten que los clientes puedan conversar en su propio idioma de dominio.
ATDD está estrechamente relacionado con el desarrollo impulsado por pruebas (TDD). [7] Se diferencia por el énfasis en la colaboración desarrollador-probador-cliente empresarial. ATDD abarca las pruebas de aceptación , pero destaca las pruebas de aceptación de escritura antes de que los desarrolladores comiencen a codificar.
Descripción general
Las pruebas de aceptación son desde el punto de vista del usuario: la vista externa del sistema. [1] Examinan los efectos visibles externamente, como especificar la salida correcta de un sistema dada una entrada en particular. Las pruebas de aceptación pueden verificar cómo cambia el estado de algo, como un pedido que pasa de "pagado" a "enviado". También pueden comprobar las interacciones con interfaces de otros sistemas, como bases de datos compartidas o servicios web. En general, son independientes de la implementación, aunque la automatización de ellos puede no serlo. [8] [9]
Creación
Las pruebas de aceptación se crean cuando se analizan los requisitos y antes de la codificación. [1] Pueden ser desarrollados en colaboración por el solicitante de requisitos (propietario del producto, analista comercial, representante del cliente, etc.), desarrollador y evaluador. Los desarrolladores implementan el sistema utilizando las pruebas de aceptación. Las pruebas fallidas proporcionan una respuesta rápida de que no se están cumpliendo los requisitos. Las pruebas se especifican en términos de dominio empresarial. Los términos luego forman un lenguaje ubicuo que se comparte entre los clientes, desarrolladores y evaluadores. [10] Las pruebas y los requisitos están interrelacionados. [11] Es posible que un requisito que carece de una prueba no se implemente correctamente. Una prueba que no se refiere a un requisito es una prueba innecesaria. Una prueba de aceptación que se desarrolla después de que comienza la implementación representa un nuevo requisito. [12]
Estrategia de prueba
Las pruebas de aceptación son parte de una estrategia de prueba general. Son las pruebas del cliente que demuestran la intención comercial de un sistema. Las pruebas de componentes son pruebas de aceptación técnica desarrolladas por un arquitecto que especifican el comportamiento de módulos grandes. El desarrollador crea las pruebas unitarias para impulsar un código fácil de mantener. [13] A menudo se derivan de pruebas de aceptación y pruebas unitarias. Las pruebas multifuncionales incluyen pruebas de usabilidad, [14] pruebas exploratorias [15] y pruebas de propiedades (escalado y seguridad). [dieciséis]
Criterios de aceptación y pruebas
Los criterios de aceptación son una descripción de lo que se verificaría mediante una prueba. Dado un requisito como "Como usuario, quiero sacar un libro de la biblioteca", un criterio de aceptación podría ser "verificar que el libro esté marcado como retirado". Una prueba de aceptación para este requisito proporciona los detalles para que la prueba se pueda ejecutar con el mismo efecto cada vez.
Formato de prueba
Las pruebas de aceptación suelen seguir este formulario: [1]
Dado (configuración)
- Un estado específico de un sistema
Cuando (disparador)
- Ocurre una acción o evento
Entonces (verificación)
- El estado del sistema ha cambiado o se ha producido una salida.
Además, es posible agregar declaraciones que comiencen con Y en cualquiera de las secciones siguientes (Dado, Cuándo, Entonces).
Para el requisito de ejemplo, los pasos podrían enumerarse como:
Dada libro que no ha sido comprobado y del usuario que está registrado en el sistema Cuando cheques usuario fuera un libro Luego libro está marcado como extraído
Prueba completa
Los pasos anteriores no incluyen ningún dato de ejemplo específico, por lo que se agrega para completar la prueba:
Dado:
- Libro que no ha sido prestado
Libros | |
---|---|
Título | Controlado |
Gran libro | No |
- Usuario que está registrado en el sistema
Usuarios | |
---|---|
Nombre | Sam |
Cuándo:
- El usuario saca un libro
Acción de pago | |||
---|---|---|---|
Usuario | Sam | Revisa | Gran libro |
Luego:
- El libro está marcado como retirado
Libros | ||
---|---|---|
Título | Controlado | Usuario |
Gran libro | sí | Sam |
Examen de prueba
El examen de la prueba con datos específicos suele dar lugar a muchas preguntas. Para la muestra, estos podrían ser:
- ¿Qué pasa si el libro ya está prestado?
- ¿Y si el libro no existe?
- ¿Qué pasa si el usuario no está registrado en el sistema?
- ¿Hay una fecha en la que se debe registrar el libro?
- ¿Cuántos libros puede sacar un usuario?
Estas preguntas ayudan a aclarar los requisitos ambiguos o faltantes. Se pueden agregar detalles adicionales como una fecha de vencimiento al resultado esperado. Otras pruebas de aceptación pueden comprobar que condiciones como intentar sacar un libro que ya está prestado producen el error esperado.
Otro ejemplo de prueba
Suponga que el cliente comercial desea una regla comercial según la cual un usuario solo puede sacar un libro a la vez. La siguiente prueba demostraría que:
Escenario: compruebe que se aplique la regla comercial de pago
Dado:
- Libro que ha sido prestado
Libros | ||
---|---|---|
Título | Controlado | Usuario |
Gran libro | sí | Sam |
Otro gran libro | No |
Usuarios |
---|
Nombre |
Sam |
Cuándo:
- El usuario saca otro libro
Acción de pago | |||
---|---|---|---|
Usuario | Sam | Revisa | Otro gran libro |
Luego:
- Se produce un error
Se produjo un error |
---|
Descripción |
Violación de la regla comercial de pago |
Pruebas de aceptación de proyectos
Además de las pruebas de aceptación de los requisitos, las pruebas de aceptación se pueden utilizar en un proyecto como un todo. [1] Por ejemplo, si este requisito fuera parte de un proyecto de préstamo de libros de la biblioteca, podría haber pruebas de aceptación para todo el proyecto. Suelen denominarse objetivos INTELIGENTES . Un ejemplo de prueba es "Cuando el nuevo sistema de biblioteca esté en producción, los usuarios podrán registrar y retirar libros tres veces más rápido que en la actualidad".
Ver también
Referencias
- ↑ a b c d e Pugh, Ken (2011). Desarrollo basado en pruebas de aceptación Lean-Agile: mejor software a través de la colaboración . Addison-Wesley. ISBN 978-0321714084.
- ^ Adzic, Gojko. (2009) Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing , Neuri Limited,
- ^ Adzic, Gojko (2011). Especificación por ejemplo: cómo los equipos exitosos entregan el software adecuado . Manning. ISBN 978-0-321-27865-4.
- ^ Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp y Dan North. El libro RSpec: desarrollo impulsado por el comportamiento con RSpec, pepino y amigos. La estantería pragmática.
- ^ "Ejemplo de diseño impulsado" . Consultado el 15 de abril de 2013 .
- ^ "Desarrollo basado en pruebas de historia" (PDF) . Consultado el 15 de abril de 2013 .
- ^ Beck, Kent. Desarrollo impulsado por pruebas: por ejemplo. Addison-Wesley Professional, 2002.
- ^ Melnik, Grigori y Frank Maurer. Melnik, Grigori; Maurer, Frank (2007). "Múltiples perspectivas sobre el desarrollo basado en pruebas de aceptación ejecutable". Procesos ágiles en Ingeniería de Software y Programación Extrema . Apuntes de conferencias en informática. 4536 . págs. 245–249. doi : 10.1007 / 978-3-540-73101-6_46 . ISBN 978-3-540-73100-9.
- ^ Koskela, Lasse. (2007) Test Driven: TDD y Acceptance TDD para desarrolladores de Java. Publicaciones Manning
- ^ Evans, Eric. (2003) Diseño basado en dominios: abordar la complejidad en el corazón del software . Addison-Wesley Professional.
- ^ Weinberg, Gerald ; Gause, Donald (1989). Explorando los requisitos: calidad antes que diseño . Casa Dorset. ISBN 0-932633-13-7.
- ^ Martin, Robert C. y Grigori Melnik. "Pruebas y requisitos, requisitos y pruebas: una tira de Möbius" (PDF) . Consultado el 15 de abril de 2013 .
- ^ [Desarrollo impulsado por pruebas]
- ^ Meszaros, Gerard y Janice Aston. (2006) "Agregar pruebas de usabilidad a un proyecto ágil". Conferencia ágil
- ^ "Explicación de las pruebas exploratorias" (PDF) .
- ^ Meszaros, Gerard. (2007) xUnit Test Patterns: Refactoring Test Code . Addison-Wesley.
enlaces externos
- Ejemplo de marcos de automatización