1
Pruebas de Aceptación
Mario Rocha Marín, Carlos Romero Hernández, Gerardo Mora Castillo
Ingeniería en Sistemas de Computación, Universidad Fidélitas
mrocha00767@ufide.ac.cr
cromero41315@ufide.ac.cr
gmora60255@ufide.ac.cr
Resumen—Las Pruebas de Aceptación son,
básicamente, la última acción de prueba previo al
despliegue general de un Software. El objetivo de las
pruebas de aceptación es, en un sentido sintético,
comprobar si el Software desarrollado está listo y
puede ser utilizado por los usuarios para realizar las
funciones necesarias y las tareas específicas para las
cuales el mismo fue diseñado. Hay ciertas estrategias
comunes para la implementación de una Prueba de
Aceptación, y la estrategia que se selecciona, suele
basarse en requisitos contractuales, estándares
corporativos de la empresa y el dominio de la
aplicación. En conclusión, es un paso de suma
importancia previo a la implementación de cualquier
Software, ya que al obviarse, puede provocar
mayores atrasos al implementar un software que no
cumple los requisitos mínimos, o cuyas
funcionalidades no se cumplen.
I. INTRODUCCIÓN
En ingeniería de Software y pruebas de software, las
pruebas de aceptación, también llamadas User
Acceptance Testing o UAT, pertenecen a las últimas
fases previas a la liberación en firme de variantes
novedosas con el propósito de establecer si cumplen con
las necesidades y/o requerimientos de las organizaciones
y sus usuarios. Al finalizar las pruebas automatizadas,
que respaldan los requisitos tecnológicos del diseño
inicial, se pasa a las pruebas manuales.
Dichas pruebas manuales primero son desarrolladas por
usuarios internos en espacios intermedios: ambientes
tradicionales de producción donde se verifica que
funciona del modo necesitado. Después viene la entrada
beta a los consumidores que de esta forma lo soliciten
repitiendo, nuevamente, el ciclo, pero en esta
oportunidad en espacios realistas y frecuentemente
bastante diferentes entre sí referente a otros softwares
agregados.
II. PRUEBAS DE ACEPTACION
Las pruebas de aceptación van muchísimo más allá de
cuando por fin se libera el software al público en general.
Se presta atención en recabar los detalles y comentarios
mediante encuestas o envíos de datos estadísticos no sin
previamente exponer un cuadro de diálogo al usuario
primerizo o con una versión nueva.
Las pruebas de aceptación tienen además la posibilidad
de aplicarse a Versiones Específicas las cuales son
desarrollos específicos de software en subconjuntos de
usuarios, ya sean preseleccionados según un criterio o
aleatoriamente. El enfoque es comprobar que todo opere
de manera correcta, en el término de que si hay un error
este sea reducido y controlado.
Son un paso de suma importancia en el proceso de
desarrollo de software, con igual importancia que los
demás pasos, a pesar de encontrarse al final del mismo
proceso. Sin este paso tan fundamental, se pueden pasar
por alto errores en el código, funcionalidades que no
cumplen las expectativas esperadas, errores de
compatibilidad con otras aplicaciones corriendo en los
ambientes de los usuarios finales y demás errores que no
se contemplan sin una prueba de aceptación final entre
una muestra considerable de usuarios. [1]
III. BENEFICIOS DE LAS PRUEBAS DE
ACEPTACION
Las pruebas de aceptación son realizadas exclusivamente
por el cliente, en conjunto con los usuarios finales, con el
motivo de determinar el nivel de confianza en el sistema
a nivel funcional, técnico y operacional, con el fin de dar
el visto bueno del software a recibir y mismo que será
implementado a lo largo de las operaciones del negocio.
Las pruebas de aceptación se realizan, tomando en cuenta
5 aspectos definidos según el ISTQB. Tales aspectos son
los presentados a continuación [2]:
A. Requerimientos del usuario
Esta sección es donde se evalúan el
Comportamiento del Software con respecto a las
necesidades del usuario y en la que se mide hasta
que nivel, el software apoyará las labores de los
usuarios.
B. Requerimientos del Sistema
Es en esta parte donde se evalúa la usabilidad de las
funciones del Software diseñado, para soportar las
operaciones de los usuarios de forma fácil e intuitiva.
C. Casos de Uso e Historias de Usuario
Es aquí donde se evalúa si el software cumple con los
criterios de aceptación definidos en las etapas previas del
desarrollo.
D. Procesos de Negocio

Es en donde se evalúan todas las funcionalidades que se
implementaron en el software para soportar todo el flujo
operacional, todo esto con el fin de aumentar la
productividad y hacer que el trabajo de los usuarios sea
menos operativo y más analítico mediante el uso de las
funciones programadas.
E. Reporte de análisis de Riesgo
Aquí se evalúan los posibles problemas que pueden
encontrarse en el software a futuro, todo esto a
nivel de rendimiento, disponibilidad y operatividad,
con el fin de determinar el riesgo para cada evento,
su probabilidad y planes de acción para su
mitigación.
IV. LIMITACIONES
1. Que el cliente no cuente con analistas de QA
en la organización, los cuales sean capaces de
probar el software.
2. Un caso donde los usuarios que ejecuten las
pruebas omitan casos de pruebas importantes
para la validación del sistema.
3. Que el cliente no cuente con personal experto
en automatización de pruebas con el fin de
reducri el tiempo de la ejecución de los casos
de prueba..
4. Que el cliente no logre comprender
correctamente las limitaciones técnicas del
software a futuro.
V. ESTRATEGIAS PARA PRUEBAS DE
ACEPTACION
Prueba de aceptación formal.
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.[3]
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.
2
 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.
Prueba de aceptación informal.
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.
Prueba de versión beta.
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 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.
 3

 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.

VI. CONCLUSIONES

En síntesis, la implementación de las pruebas de

aceptación es un paso muy importante dentro del
desarrollo de software ya que permite que se mejoren los
procesos de implementación y de igual manera, permiten
que los usuarios tengan una mejor experiencia en
general, mediante el desarrollo de casos de prueba e
informes de errores.

La obviedad de este recurso puede provocar diferentes

problemas desde que surjan problemas con la aplicación,
errores de compatibilidad con otros software en el
ambiente de los usuarios o la falta de cumplimiento de
las expectativas acordadas en etapas iniciales del
desarrollo.

VII. BIBLIOGRAFÍA

[1] Ellingwood, Justin (20 de mayo de 2017). «An

Introduction to Continuous Integration, Delivery, and
Deployment».
[2] El Portal Web, «Pruebas de Aceptación de
Software,» 15 de abril 2015. [En línea]. Available at:
https://www.causa-efecto-propuesta.com/Ingenieria/P
ruebas-de-aceptacion-de-software-506.php
[3] «Concepto: Prueba de aceptación» Tech
Republic, [En línea]. Available at:
https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/co
re.base_rup/guidances/concepts/
acceptance_testing_12A0F152.html