Pruebas de Aceptación

Navarrete Rivera Víctor Manuel

Armenta Daza Mario
Introducción
Es una prueba formal que se lleva a cabo para
determinar si un sistema se ajusta a los criterios de
aceptación y que permite al cliente determinar si
acepta o no el sistema.

Cada prueba de aceptación trata de probar la

funcionalidad de una historia de usuario.
Propiedades de las pruebas de aceptación
Responsabilidad del cliente. Las pruebas de
aceptación deben ser  responsabilidad del cliente,
porque su propósito principal es especificar los
criterios de aceptación de la historia de usuario.
Escrita en colaboración con el cliente el desarrollador
y probador. Nadie debe terminar aislándose del
proceso debido a la falta de entendimiento.
Expresados en la lengua del dominio del problema.
Una propiedad importante de las pruebas de
aceptación es que utilicen el lenguaje de dominio del
problema que el cliente entiende en lugar de hablar
sólo el que entiende el programador.
Concisa, precisa y sin ambigüedades. Escribimos cada
una de nuestras pruebas de aceptación para verificar
un sólo aspecto  de una situación relevante para la
historia de usuario.
¿Qué es una prueba de aceptación?
La prueba de aceptación es por lo menos el modelo y,
posiblemente, incluso por escrito del cliente. De ahí el
nombre más reciente, CustomerTest.
Propuesto por KentBeck en una encuesta sobre la
XpMailingList a principios de abril de 2000. Aprobado
por el comité. Ahora, el término estándar en Windows
XP.
Las pruebas de aceptación son el último paso antes de
la entrega formal del software al cliente y se realiza,
normalmente, en el entorno del usuario.
Consiste en la aceptación por parte del cliente del
software desarrollado.
Propósito PA
Una PA tiene como propósito demostrar al cliente el
cumplimiento de un requisito del software.
Precisando un poco más, una PA:
Describe un escenario (secuencia de pasos) de ejecución
o uso del sistema desde la perspectiva del cliente.
Puede estar asociada a requisitos funcionales o no.
Las PAs cubren desde escenarios típicos/frecuentes
hasta los más excepcionales.
Ejemplo
Como administrador de venta, me gustaría que los
precios se identificasen para un cliente para que puedan
proporcionar con el costo.
Por desgracia, mientras que sigue el formato,
proporciona alguna información muy flexible y no
proporcionar un punto de partida para la
implementación. Un ejemplo aún mejor sería:
Como administrador de venta, desea poder ver los
precios de productos x, para que puedan proporcionar los
clientes con un costo preciso basándose en sus requisitos.
¿Quién escribe y quién comprueba las
pruebas de aceptación?
El cliente es la persona en la que recae el 70% u 80% ya
que el determina, si el sistema hace lo que debería
hacer, lo que el necesita que haga.
Como se mencionaba antes el cliente, el desarrollador
y el probador deben estar implicados en la realización
de estas pruebas.
Requisitos versus Pruebas de Aceptación
El proceso de desarrollo debe estar dirigido por los
requisitos. Obvio puesto que los requisitos son el
objetivo a cumplir, sin embargo, …
¿Popularmente cómo se especifican los requisitos?
Textualmente
UML (Diagramas de Casos de Uso y otros diagramas)
Plantillas o fichas
Interfaces de usuario (bocetos)
CONCLUSIONES
Requisitos y PAs conducen el proceso de desarrollo.