Este documento describe diferentes tipos de pruebas de sistemas y aceptación. Las pruebas de sistema validan los requisitos funcionales y no funcionales, mientras que las pruebas de aceptación, como las UAT, operativas, de contrato, alfa y beta, garantizan que el sistema cumple las expectativas del cliente antes de la producción. Las pruebas de aceptación involucran a los usuarios finales y se realizan en entornos preproductivos.
2. Competencias
• Definir los conceptos básicos de las pruebas de sistema.
• Definir los conceptos básicos de las pruebas de aceptación.
3. Índice
• Introducción
• Pruebas de sistema
• Pruebas de aceptación
– Pruebas UAT
– Pruebas Operativas
– Pruebas de Aceptacion de Contrato
– Pruebas Alfa y Beta
4. Introducción
• Si los usuarios finales encuentran errores en las aplicaciones, esto afecta
su confianza en la aplicaciones, y como consecuencia optaran por otras
alternativas.
• Por esta razón, en las pruebas de software se deben eliminar tantos
errores como sea posible antes que la aplicación estén puestas en
producción.
5. Pruebas de Sistema
• Las pruebas de sistema deben de validar los requisitos funcionales y no
funcionales del sistema y las características de calidad en el entorno final.
Para ello se aplicarán técnicas de prueba de caja negra.
6. Pruebas de Aceptación (1/2)
• Las pruebas de aceptación son ejecutadas por el representante del cliente
y podria ser la única parte de las pruebas en donde estén involucrados.
• Estas pruebas se llevan a cabo antes de que el programa se ponga en
producción y tienen que satisfacer las expectativas del cliente.
7. Pruebas de Aceptación (2/2)
• Hay cuatro formas típicas de las pruebas de aceptación [ISTQB]:
– Pruebas de aceptación del usuario (UAT).
– Pruebas de aceptación del contrato.
– Pruebas operativas.
– Pruebas alfa y beta.
8. Pruebas de Aceptación del usuario (UAT).
• Se enfocan en verificar si el sistema es “apto para el uso”.
• Se diseñan principalmente a partir de los requerimientos, casos de uso,
historia de usuarios y de los procesos de negocio definidos
• Los usuarios y clientes se involucran en la ejecución de las pruebas.
• Se ejecutan en los entornos de preproductivo, en algunos casos se
ejecutan en entornos productivos.
9. Pruebas Operativas
• Comprende la aceptación del nuevo sistema o funcionalidad por parte de
del área de operaciones de informática de la organización, se evalúan
temas como:
– Pruebas de respaldo y recuperación.
– Control de acceso al sistema.
– Mantenimiento.
– Carga y migración de datos.
– Revisión de vulnerabilidades del sistema
10. Pruebas de Aceptación del Contrato
• Se da cuando se haya firmado un contrato para desarrollar software a la
medida.
• Se pueden definirse pruebas de aceptación en función de las cláusulas de
dicho contrato.
• Las pruebas de aceptación de regulaciones se realizan verificando que la
funcionalidad del sistema cumple con las regulaciones, tales como las
definidas por el gobierno, las leyes o estándares de seguridad.
11. Pruebas Alfa y Beta.
• Se realizan para tener un feedback de los potenciales usuarios del futuro
software.
• Las pruebas Alfa son realizadas por la misma organización desarrolladora
del software, pero no por el equipo de desarrollo (Por ejemplo un equipo de
pruebas de software).
• Las pruebas Beta son realizadas por clientes existen o potenciales en sus
propias instalaciones. A estas pruebas también se les conoce como
pruebas de campo.
12. BIBLIOGRAFÍA
• Ron Patton. “Software Testing” Segunda Edición. Sams Publishing 2005.
• Roger S. Pressman. “Ingeniería del Software: Un enfoque practico. Sexta
edición”. Mc Graw Hill 2005.
• Roger S. Pressman. “Ingeniería del Software: Un enfoque practico. Quinta
edición”.
• Glenford J. Myers. “The art of software testing”. Segunda edición. John
Wiley & Sons 2004.
Notas del editor
Las pruebas están dentro de estos modelos de maneras muy diferentes. Por ejemplo, dentro del modelo en cascada las pruebas se ejecutan al final del proyecto y dentro del modelo en V se realizan en los diferentes niveles de desarrollo.
Las pruebas están dentro de estos modelos de maneras muy diferentes. Por ejemplo, dentro del modelo en cascada las pruebas se ejecutan al final del proyecto y dentro del modelo en V se realizan en los diferentes niveles de desarrollo.
Las pruebas están dentro de estos modelos de maneras muy diferentes. Por ejemplo, dentro del modelo en cascada las pruebas se ejecutan al final del proyecto y dentro del modelo en V se realizan en los diferentes niveles de desarrollo.
El proceso de prueba comienza en enfocarse sobre aquellos aspectos de ésta que son visibles para el usuario y procede a probar dicha tecnología e infraestructura. La prueba consta de siete etapas: contenido, interfaz, navegación, componente, configuración, desempeño y prueba de seguridad.
En algunos casos se produce un plan de prueba de la Aplicación Web. En todos los casos se desarrolla un conjunto de casos de prueba para cada etapa de la prueba y se observa un archivo de resultados de pruebas para uso futuro.
Aunque nunca se puede estar seguro de que han llevado a cabo todas las pruebas que se necesitan, puede tenerse la seguridad de que la puesta en prueba ha descubierto errores ( y que éstos se han corregido). Además, si se ha establecido un plan de prueba, puede verificarse para asegurar que se han realizado todas las pruebas planeadas.
El ISTQB nos dice que las pruebas de sistemas pueden incluir pruebas basadas en riesgos y/o especificaciones de requisitos, procesos de negocio, casos de uso u otras descripciones de texto de alto nivel o modelos de comportamiento de sistema, interacciones con el sistema operativo y recursos del sistema.
