La prueba de aceptación es la última acción de prueba antes de desplegar el software. El objetivo de la prueba de
aceptación es comprobar si el software está preparado y lo pueden utilizar los usuarios para realizar las funciones y
tareas para las que se diseñó. Hay tres estrategias comunes para implementar una prueba de aceptación. Esos principios
son:
La estrategia que seleccione suele basarse en los requisitos contractuales, los estándares corporativos y de la empresa
y el dominio de la aplicación.
Las pruebas de aceptación formal es un proceso altamente gestionado y, a menudo, una ampliación de la prueba del
sistema. Las pruebas se planifican y diseñan con el mismo cuidado, y el mismo nivel de detalle, que las pruebas del
sistema. Los casos de prueba seleccionados deben ser un subconjunto de los realizados en la prueba del sistema. Es
importante no desviarse en absoluto de los casos de prueba escogidos. En muchas empresas, las pruebas de aceptación
formal son totalmente automatizadas.
Los productos de trabajo y las tareas son los mismos que para las pruebas del sistema. En algunas empresas, la empresa
de desarrollo (o el grupo de prueba independiente), junto con los representantes de la empresa del usuario final, lleva
a cabo la prueba de aceptación. En otras, las pruebas de aceptación las lleva a cabo en su totalidad la empresa del
usuario final o un grupo objetivo de personas escogidas por la empresa del usuario final.
Los beneficios de esta forma de prueba son:
-
Las funciones y las características que se van a probar son conocidas.
-
Los detalles de las pruebas se conocen y se pueden medir.
-
Las pruebas se pueden automatizar, lo que permite realizar pruebas de regresión.
-
El progreso de las pruebas se puede medir y supervisar.
-
Los criterios de aceptabilidad son conocidos.
Las desventajas incluyen:
-
Requiere una planificación y recursos significativos.
-
Las pruebas pueden ser una reimplementación de las pruebas del sistema.
-
Es posible que las pruebas no revelen defectos subjetivos en el software, ya que sólo busca defectos que espera
encontrar.
En las pruebas de aceptación informal, los procedimientos para realizar la prueba no se definen tan rigurosamente como
para las pruebas de aceptación formal. Las actividades empresariales y las funciones que se explorarán se identifican y
documentan, pero no hay casos de prueba particulares que seguir. El verificador individual determina qué hacer. Esta
propuesta de prueba de aceptación no está tan controlada como la prueba formal y es más subjetiva.
Las pruebas de aceptación informal las suele realizar la empresa del usuario final.
Los beneficios de esta forma de prueba son:
-
Las funciones y las características que se van a probar son conocidas.
-
El progreso de las pruebas se puede medir y supervisar.
-
Los criterios de aceptabilidad son conocidos.
-
Revela defectos más subjetivos que la prueba de aceptación formal.
Las desventajas incluyen:
-
Son necesarios recursos de gestión, planificación y recursos.
-
No se tiene control de los casos de prueba que se utilizan.
-
Los usuarios pueden adaptarse al funcionamiento del sistema y no apreciar los defectos.
-
Los usuarios pueden centrarse en la comparación del sistema nuevo con un sistema heredado, en vez de buscar
defectos.
-
Los recursos de la prueba de aceptación no se encuentran bajo el control del proyecto y pueden limitarse.
La prueba de versión beta es la menos controlada de las tres estrategias de prueba de aceptación. En la prueba de
versión beta, la cantidad de detalles y datos y el enfoque adoptado dependen totalmente del verificador individual.
Cada verificador es responsable de crear su propio entorno, seleccionar los datos y determinar las funciones,
características o tareas que va a explorar. Cada verificador es responsable de identificar sus criterios para aceptar o
no el sistema en su estado actual.
La prueba de versión beta la implementan los usuarios, a menudo con poca o ninguna gestión por parte de la empresa de
desarrollo (u otro usuario no final). La prueba de versión beta es la más subjetiva de todas las estrategias de prueba
de aceptación.
Los beneficios de esta forma de prueba son:
-
La prueba la implementan los usuarios.
-
Hay grandes volúmenes de recursos de prueba potenciales.
-
Los clientes que participan están cada vez más satisfechos.
-
Revela defectos más subjetivos que las pruebas de aceptación formal e informal.
Las desventajas incluyen:
-
Es posible que no pueda probar todas las funciones o características.
-
El progreso de la prueba es difícil de medir.
-
Los usuarios pueden adaptarse al funcionamiento del sistema y no apreciar o notificar los defectos.
-
Los usuarios pueden centrarse en la comparación del sistema nuevo con un sistema heredado, en vez de buscar
defectos.
-
Los recursos de la prueba de aceptación no se encuentran bajo el control del proyecto y pueden limitarse.
-
Los criterios de aceptabilidad no son conocidos.
-
Necesita más recursos de soporte para gestionar a los verificadores de beta.
|