NIVELES DE PRUEBA
• Pruebas de componentes
• Pruebas de integración
• Pruebas del sistema
• Pruebas de aceptación
Pruebas de componentes:
Primera fase de pruebas.
Se realizan sobre cada módulo o componente del software que se pueda de manera independiente.
Se llaman pruebas de Modulo o Unitarias.
Modulo: Unidad mínima de un sistema. (EJ: en una calculadora: Suma, Resta, Multiplicación. División).
En algunas ocasiones los módulos necesitan interactuar con otros módulos que no están disponibles al
momento de la prueba. Se sustituyen por STUBS o DRIVERS (Mock Objects) que simulan el software faltante de
una manera simple.
STUB: Simula una respuesta.
DRIVER: Simula una llamada.
Para cada nivel de pruebas se deben definir:
1. Objetivos:
- Conseguir defectos y fallas
- Reducir el riesgo
- Construir confianza en la calidad del componente
- Prevenir que los defectos escalen a niveles de prueba más altos
2. Objetos a probar:
- Componentes, unidades o módulos
- Código o estructura de datos
- Clases
- Módulos de bases de datos
3. Bases de prueba:
- Diseño detallado
- Modelo de datos
- Especificaciones de componentes
- Código fuente
4. Defectos comunes:
- Funcionamiento incorrecto
- Problemas en el flujo de datos
- Código y lógica incorrecta en el código
5. Responsabilidades:
La prueba de componentes usualmente es responsabilidad del Developer porque se necesita acceso al código
fuente.
Sin embargo, en desarrollos agiles los casos de prueba podrían escribirse antes que el código fuente.
-Desarrollo basado en pruebas (Test Driven Development o TDD): se basa en ciclos de desarrollo de casos de
prueba automatizados: construir e integrar pequeñas piezas de código, ejecutar las pruebas de componentes,
corregir cualquier problema y reconstruir el código. Este proceso continúa hasta que el componente se haya
construido por completo y todas las pruebas de componentes hayan pasado.
Pruebas de integración:
Sirven para asegurar que la comunicación, enlaces y datos compartidos entre módulos o con diferentes partes
del sistema funcionan correctamente.
Antes de las pruebas de integración, los componentes tuvieron que haber pasado sus pruebas unitarias, por lo
que el enfoque ahora es sobre el flujo de control entre los módulos y sobre los datos que son intercambiados
entre ellos de manera independiente.
NIVELES:
-Pruebas de integración de componentes:
-Prueban las interacciones entre componentes.
-Se realizan después de las pruebas de componentes y en general son automatizados.
-Son parte del proceso de integración continua.
-Pruebas de integración de sistemas:
- Prueban interacciones entre sistemas, paquetes y servicios.
- Se realizan después o en paralelo de las pruebas de sistemas.
1. Objetivos:
-Conseguir defectos y fallas en las interfaces y módulos.
- Reducir el riesgo.
- Construir confianza en la calidad de las interfaces.
-Prevenir defectos que escalen a niveles más altos.
2. Bases de prueba:
- Subsistemas
- Bases de datos
- Infraestructura
- Interfaces
- Interfaces de comunicación de aplicaciones (API’S)
- Microservicios
3. Objetos de prueba:
- Diseño de software y sistemas
- Diagrama de secuencias
- Especificaciones de interfaz y protocolos de comunicación
- Casos de uso
- Arquitectura
- Flujos de trabajo
- Definiciones de interfaces externas
4. Defectos comunes:
- Datos incorrectos, faltantes o mal codificados
- Defectos en las llamadas de interfaz
- Incompatibilidad de la interfaz
- Fallos en la comunicación de componentes
- Fallos en la comunicación ENTRE componentes
- Suposiciones incorrectas.
Enfoque de prueba de integración:
BIG-BANG: Todos los componentes o sistemas se integran simultáneamente. Se prueba como un todo y tiene
la ventaja de estar terminado antes de las pruebas de integración.
Desventaja: Consume mucho tiempo y es difícil rastrear donde están las fallas.
PRUEBA INCREMENTAL: Todos los programas se integran uno por uno y se realiza una prueba después de cada
paso.
Ventaja: Los defectos se encuentran temprano en un ensamblaje más pequeño.
Desventaja: Se puede llevar mucho tiempo ya que los stubs y los controladores deben desarrollarse y usarse
en la prueba.
Hay 2 tipos de prueba incremental.
TOP DOWN (Descendente): las pruebas se realizan de arriba hacia abajo, siguiendo el flujo de control de la
estructura arquitectónica.
BOTTOM UP (Ascendente): de abajo hacia arriba, las pruebas se realizan desde la parte inferior hacia arriba.
Los componentes o sistemas se sustituyen por controladores.
INCREMENTAL FUNCIONAL: La integración y las pruebas se realizan en función de las funciones o la
funcionalidad. La secuencia de integración escogida y el número de pasos requerido debería depender de la
ubicación de las interfaces de alto riesgo dentro de la arquitectura. La mejor opción es comenzar por aquellas
interfaces que se espera que causen la mayoría de los problemas y evitar defectos importantes al final de la
etapa de prueba de integración.
Pruebas de Sistema:
Sirve para verificar que se han integrado adecuadamente todos los elementos del sistema y que funciona
apropiadamente como un todo.
Tipos de pruebas:
- Pruebas basadas en riesgos
- Especificaciones de requisitos
- Procesos de negocio
- Casos de uso
- Interacciones con el sistema operativo y recursos del sistema
Suele ser la prueba final a nivel desarrollo. Verifica que el sistema entregado cumple con la especificación. Su
propósito es encontrar tantos defectos como sea posible.
1. Objetivos:
- Reducir el riesgo
- VERIFICAR y VALIDAR el sistema
- VALIDAR que el sistema está completo y funciona como se espera
- Generar confianza en la calidad del sistema en su conjunto
- Encontrar defectos
- Evitar que los defectos escalen a niveles más altos
2. Objetos de prueba:
- Aplicaciones: es necesario que el entorno no genere consecuencias negativas
- Hardware y Software: el sistema interactúa con dispositivos de hardware como impresoras, tarjetas de video,
etc. Dicha interacción debe estar garantizada para evitar afectar el sistema bajo prueba
- Sistemas operativos: garantizar que el sistema es capaz de operar bajo los distintos sistemas operativos que
fueron considerados.
-Sistema bajo prueba (SBP).
- Configuración y datos de configuración.
3. Base de prueba:
- Especificaciones de requisitos del sistema y software
- Informes de análisis de riesgo
- casos de uso
- Épicas e historias de usuario: Épica es una historia de usuario muy larga que debe ser dividida en múltiples
historias de usuarios.
- Modelos de comportamiento del sistema
- Diagramas de estado
- Manuales de sistema y usuario
4. Defectos comunes:
- Cálculos incorrectos
- Comportamiento incorrecto o inesperado de tareas funcionales o no funcionales del sistema.
- Control de datos o flujo de datos incorrectos en el sistema
- Flujo completo de tareas que no funcionan: pruebas de todos los escenarios reales relacionados al uso del
sistema
- Funcionamiento incorrecto del sistema en el entorno de producción (fallas de validación)
- Fallas en la verificación
Pruebas de aceptación:
Se ejecutan en un entorno de pruebas lo más parecido posible al entorno de producción.
La prueba de aceptación debe responder preguntas como:
- Se puede liberar el sistema?
- Cuales son los riesgos de negocio pendientes?
- Se cumplieron los objetivos?
Las pruebas de aceptación se centran en determinar si el sistema es adecuado para su propósito. Su principal
objetivo es establecer confianza en el uso del sistema.
Si se consigue un número significativo de defectos durante las pruebas puede significar un riesgo mayor para
el proyecto.
Las pruebas de aceptación se pueden realizar durante otros niveles de prueba. Pueden ser de diversos tipos,
dependiendo de cual parte del sistema se está validando.
Cada tipo de prueba se prepara y se ejecuta por separado
- Pruebas de Aceptación de Usuario (UAT – User Acceptance Testing): Se centra en validar que el sistema
cumple los requisitos de funcionamiento esperado en un entorno real o simulado.
1. Se asegura de que los usuarios puedan usar el sistema para satisfacer sus necesidades
2. Cumplimiento de requisitos
3. Realizar procesos de negocio con mínima dificultad, costo y riesgo
- Pruebas de Aceptación Operacional (OAT – Operational Acceptance Testing): Se valida si el sistema cumple
con los requisitos de operación. La realizan los usuarios y los administradores de la app.
Genera confianza en que los operadores o administradores del sistema pueden mantener el sistema
funcionando correctamente para los usuarios en el entorno operativo.
- Pruebas de Aceptación Contractuales y Regulatorias: El objetivo principal es generar confianza en que se ha
logrado el cumplimiento contractual y reglamentario (Normativas a cumplir como regulaciones
gubernamentales, legales o de seguridad)
-Pruebas de Aceptación Alfa y Beta: suelen ser utilizadas por desarrolladores de un producto de software
comercial. Las pruebas Alfa se realizan en las instalaciones de la organización que desarrolla, generalmente
clientes potenciales o existentes, operadores o un equipo de prueba independiente.
La prueba Beta es realizada por clientes potenciales o existentes en sus propias ubicaciones (fuera de la
instalación de la organización que desarrolla). Puede realizarse después de la prueba Alfa.
Ambas pruebas se utilizan para generar confianza entre los clientes u operadores para lograr sus objetivos con
mínima dificultad, costo y riesgo. También se pueden detectar defectos relacionados con las condiciones del
entorno en el que se utilizara el sistema.
1. Base de pruebas:
- Procesos de negocio
- Requisitos del Usuario/Negocio
- Regulaciones, contratos legales y estándares
- Casos de Uso
- Requisitos del sistema
- Documentación del sistema/usuario
- Procedimientos de instalación
- Informes de análisis de riesgos
Pruebas de aceptación operativa:
- Procedimientos de respaldo y restauración
- Procedimientos de recuperación ante desastres
- Requisitos no funcionales
- Documentos de Operaciones
- Instrucciones de despliegue e instalación
- Objetivos de rendimiento
- Paquetes de bases de datos
- Normas o regulaciones de seguridad
2. Objetos de prueba:
- Sistema bajo prueba
- Configuración del sistema y datos de configuración
- Procesos empresariales
- Sistemas de recuperación
- Procesos operativos y de mantenimiento
- Formularios
- Reportes
- Datos de producción existentes y convertidos
3. Defectos comunes:
- Flujos de trabajo incorrectos
- Reglas de negocio mal implementadas
- Regulaciones mal implementadas
- Fallas no funcionales: vulnerabilidad de seguridad, eficiencia de rendimiento inadecuada bajo cargas altas u
operación incorrecta
4. Responsabilidades:
- Clientes
- Usuarios de negocio
- Dueño del producto
- Operadores de sistema
