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.
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]
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]
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]
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.
Las pruebas de aceptación suelen seguir este formato: [1]
Dado (configuración)
Cuando (disparador)
Luego (verificación)
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.Los pasos anteriores no incluyen ningún dato de ejemplo específico, por lo que se agrega para completar la prueba:
Dado:
Cuando:
Entonces:
El examen de la prueba con datos específicos suele dar lugar a muchas preguntas. En el ejemplo, estas podrían ser:
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.
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:
Cuando:
Entonces:
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".