Desarrollo basado en pruebas de aceptación

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 ejemplos (EDD), ^[5] y el desarrollo impulsado por soporte también llamado desarrollo impulsado por pruebas de historias (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 lenguaje de dominio.

El ATDD está estrechamente relacionado con el desarrollo impulsado por pruebas (TDD). ^[7] Se diferencia por el énfasis en la colaboración entre el desarrollador, el evaluador y el cliente comercial. El ATDD abarca las pruebas de aceptación , pero destaca la redacción de pruebas de aceptación antes de que los desarrolladores comiencen a codificar.

Descripción general

Las pruebas de aceptación se realizan desde el punto de vista del usuario, es decir, desde la perspectiva externa del sistema. ^[1] Examinan los efectos visibles desde el exterior, como la especificación de la salida correcta de un sistema dada una entrada 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 verificar las interacciones con interfaces de otros sistemas, como bases de datos compartidas o servicios web. En general, son independientes de la implementación, aunque su automatización 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 desarrollarse de forma colaborativa entre el solicitante del requisito (dueño del producto, analista de negocios, representante del cliente, etc.), el desarrollador y el evaluador. Los desarrolladores implementan el sistema utilizando las pruebas de aceptación. Las pruebas fallidas proporcionan una retroalimentación rápida de que no se están cumpliendo los requisitos. Las pruebas se especifican en términos del dominio empresarial. Luego, los términos forman un lenguaje ubicuo que se comparte entre los clientes, los desarrolladores y los evaluadores. ^[10] Las pruebas y los requisitos están interrelacionados. ^[11] Un requisito que carece de una prueba puede no implementarse correctamente. Una prueba que no hace referencia 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 de 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. Las pruebas unitarias son creadas por el desarrollador 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 (escalabilidad y seguridad). ^[16]

Criterios de aceptación y pruebas

Los criterios de aceptación son una descripción de lo que se comprobaría mediante una prueba. Dado un requisito como "Como usuario, quiero retirar 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 pueda ejecutarse con el mismo efecto cada vez.

Formato de prueba

Las pruebas de aceptación suelen seguir este formato: ^[1]

Dado (configuración)

Un estado específico de un sistema

Cuando (disparador)

Ocurre una acción o un acontecimiento

Luego (verificación)

El estado del sistema ha cambiado o se ha producido una salida.

Además, es posible agregar declaraciones que comiencen con AND en cualquiera de las secciones siguientes (Dado, Cuando, Entonces).

Para el requisito de ejemplo, los pasos podrían enumerarse de la siguiente manera:

Dado un libro que no ha sido prestado y un usuario que está registrado en el sistema , cuando el usuario presta un libro , el libro se marca como prestado.

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	Revisado
Gran libro	No

Usuario que está registrado en el sistema

Usuarios
Nombre	Sam

Cuando:

El usuario saca un libro prestado

Acción de pago
Usuario	Sam	Revisa	Gran libro

Entonces:

El libro está marcado como prestado

Libros
Título	Revisado	Usuario
Gran libro	Sí	Sam

Examen de prueba

El examen de la prueba con datos específicos suele dar lugar a muchas preguntas. En el ejemplo, estas podrían ser:

¿Qué pasa si el libro ya está prestado?
¿Qué pasa si el libro no existe?
¿Qué pasa si el usuario no está registrado en el sistema?
¿Existe una fecha en la que se debe devolver el libro?
¿Cuántos libros puede retirar un usuario?

Estas preguntas ayudan a identificar requisitos ambiguos o que faltan. Se pueden agregar detalles adicionales, como una fecha de entrega, al resultado esperado. Otras pruebas de aceptación pueden verificar que condiciones como intentar retirar un libro que ya está retirado produzcan el error esperado.

Otro ejemplo de prueba

Supongamos que el cliente empresarial desea una regla empresarial que establezca que un usuario solo puede retirar un libro a la vez. La siguiente prueba lo demostraría:

Escenario: comprobar que se aplica la regla comercial de pago

Dado:

Libro que ha sido prestado

Libros
Título	Revisado	Usuario
Gran libro	Sí	Sam
Otro gran libro	No

Usuarios
Nombre
Sam

Cuando:

El usuario consulta otro libro

Acción de pago
Usuario	Sam	Revisa	Otro gran libro

Entonces:

Se produjo un error

Se produjo un error
Descripción
Violación de las normas comerciales de pago

Pruebas de aceptación del proyecto

Además de las pruebas de aceptación de los requisitos, las pruebas de aceptación se pueden utilizar en un proyecto en su conjunto. ^[1] Por ejemplo, si este requisito formaba parte de un proyecto de préstamo de libros de una biblioteca, se podrían realizar pruebas de aceptación para todo el proyecto. Estas pruebas suelen denominarse objetivos SMART . Un ejemplo de prueba es "Cuando el nuevo sistema de biblioteca esté en producción, los usuarios podrán prestar y retirar libros tres veces más rápido que en la actualidad".

Véase también

Referencias

^ abcde Pugh, Ken (2011). Desarrollo basado en pruebas de aceptación ágil y esbelta: mejor software mediante la colaboración . Addison-Wesley. ISBN 978-0321714084.
^ Adzic, Gojko. (2009) Cerrando la brecha de comunicación: especificación mediante ejemplos y pruebas de aceptación ágiles , Neuri Limited,
^ Adzic, Gojko (2011). Especificación mediante el 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 de RSpec: desarrollo impulsado por la conducta con RSpec, Cucumber y amigos. The Pragmatic Bookshelf.
^ "Diseño basado en ejemplos" . Consultado el 15 de abril de 2013 .
^ "Desarrollo basado en pruebas de historias" (PDF) . Consultado el 15 de abril de 2013 .
^ Beck, Kent. Desarrollo basado en pruebas: con ejemplos. Addison-Wesley Professional, 2002.
^ Melnik, Grigori y Frank Maurer. Melnik, Grigori; Maurer, Frank (2007). "Perspectivas múltiples sobre el desarrollo basado en pruebas de aceptación ejecutable". Procesos ágiles en ingeniería de software y programación extrema . Apuntes de clase en informática. Vol. 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 TDD de aceptación para desarrolladores de Java. Publicaciones de Manning
^ Evans, Eric. (2003) Diseño impulsado por el dominio: abordar la complejidad en el corazón del software . Addison-Wesley Professional.
^ Weinberg, Gerald ; Gause, Donald (1989). Explorando los requisitos: la calidad antes que el diseño . Dorset House. ISBN 0-932633-13-7.
^ Martin, Robert C. y Grigori Melnik. "Pruebas y requisitos, requisitos y pruebas: una cinta de Möbius" (PDF) . Consultado el 15 de abril de 2013 .
^ [Desarrollo basado en pruebas]
^ Meszaros, Gerard y Janice Aston. (2006) "Añadir pruebas de usabilidad a un proyecto ágil". Conferencia Agile
^ "Explicación de las pruebas exploratorias" (PDF) .
^ Meszaros, Gerard.(2007) Patrones de pruebas unitarias: refactorización del código de prueba . Addison-Wesley.

Enlaces externos

Ejemplos de marcos de automatización

[Pugh11-1] Pugh, Ken (2011). Desarrollo basado en pruebas de aceptación ágil y esbelta: mejor software mediante la colaboración . Addison-Wesley. ISBN 978-0321714084.

[2] Adzic, Gojko. (2009) Cerrando la brecha de comunicación: especificación mediante ejemplos y pruebas de aceptación ágiles , Neuri Limited,

[3] Adzic, Gojko (2011). Especificación mediante el ejemplo: cómo los equipos exitosos entregan el software adecuado . Manning. ISBN 978-0-321-27865-4.

[4] Chelimsky, David, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp y Dan North. El libro de RSpec: desarrollo impulsado por la conducta con RSpec, Cucumber y amigos. The Pragmatic Bookshelf.

[5] "Diseño basado en ejemplos" . Consultado el 15 de abril de 2013 .

[6] "Desarrollo basado en pruebas de historias" (PDF) . Consultado el 15 de abril de 2013 .

[7] Beck, Kent. Desarrollo basado en pruebas: con ejemplos. Addison-Wesley Professional, 2002.

[8] Melnik, Grigori y Frank Maurer. Melnik, Grigori; Maurer, Frank (2007). "Perspectivas múltiples sobre el desarrollo basado en pruebas de aceptación ejecutable". Procesos ágiles en ingeniería de software y programación extrema . Apuntes de clase en informática. Vol. 4536. págs. 245–249. doi :10.1007/978-3-540-73101-6_46. ISBN . 978-3-540-73100-9.

[9] Koskela, Lasse. (2007) Test Driven: TDD y TDD de aceptación para desarrolladores de Java. Publicaciones de Manning

[10] Evans, Eric. (2003) Diseño impulsado por el dominio: abordar la complejidad en el corazón del software . Addison-Wesley Professional.

[11] Weinberg, Gerald ; Gause, Donald (1989). Explorando los requisitos: la calidad antes que el diseño . Dorset House. ISBN 0-932633-13-7.

[12] Martin, Robert C. y Grigori Melnik. "Pruebas y requisitos, requisitos y pruebas: una cinta de Möbius" (PDF) . Consultado el 15 de abril de 2013 .

[13] [Desarrollo basado en pruebas]

[14] Meszaros, Gerard y Janice Aston. (2006) "Añadir pruebas de usabilidad a un proyecto ágil". Conferencia Agile

[15] "Explicación de las pruebas exploratorias" (PDF) .

[16] Meszaros, Gerard.(2007) Patrones de pruebas unitarias: refactorización del código de prueba . Addison-Wesley.