Según Roger S. Pressman, las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón, se define una plantilla para las pruebas del software.
Una estrategia de prueba del software tiene las siguientes características generales:
· Las pruebas comienzan a nivel de módulo (en los sistemas orientados a objetos, las pruebas empiezan a nivel de clase o de objeto) y trabajan “hacia fuera”, hacia la integración de todo el sistema.
· Según el momento, son apropiadas diferentes técnicas de prueba
· La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas.
· La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba
Una estrategia de prueba de software proporciona una guía al profesional y proporciona un conjunto de hitos para el jefe de proyecto.
Verificación y validación
|
Verificación |
|
Es el conjunto de actividades que aseguran que el software implementa correctamente una función específica. ¿Estamos construyendo el producto correctamente? |
|
Validación |
|
Es el conjunto de actividades diferentes que aseguran que el software construido se ajusta a los requisitos del cliente. ¿Estamos construyendo el producto correcto? |
Organización para las pruebas del software
Toda prueba de software debe tener la coordinación de actividades:
· El responsable del desarrollo del software es el responsable de probar las unidades del programa y a veces se encarga también de la prueba de integración.
· Cuando se tiene una arquitectura completa de software, los encargados de la prueba es un Grupo Independiente de Prueba (GIP), permitiendo que se tenga independencia.
Grupo Independiente de prueba
Este grupo tiene como objetivo identificar y encontrar errores. Este grupo trabaja conjuntamente con el responsable del desarrollo de software para asegurar que se realizan pruebas exhaustivas. Mientras se realiza la prueba, el desarrollador debe estar disponible para corregir los errores que se van descubriendo.
Estrategia de prueba del software
Los niveles de la estrategia para la prueba del software se pueden ver en el siguiente grafico:
Si se considera el proceso desde el punto de vista procedimental, la prueba, en el contexto de la ingeniería del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente.
1. La prueba se centra en cada módulo individualmente, asegurando que funcionan adecuadamente como una unidad. La prueba de unidad hace uso de las técnicas de prueba de caja blanca, ejercitando caminos específicos de la estructura de control del módulo para asegurar un alcance completo y una detección máxima de errores.
2. Se ensamblan o integran los módulos para formar el paquete de software completo. La prueba de integración se dirige a todos los aspectos asociados con el doble problema de verificación y de construcción del programa. Durante la integración, las técnicas que más prevalecen son las de diseño de casos de prueba de caja negra, aunque se pueden llevar a cabo algunas pruebas de caja blanca con el fin de asegurar que se cubren los principales caminos de control.
3. Después de que el software se ha integrado (construido), se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validación. La prueba de validación proporciona una seguridad final de que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
4. La prueba del sistema verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.
ASPECTOS ESTRATÉGICOS
Si se desea implementar una estrategia de software con éxito se debe plantea que se deben abordar los siguientes si se desea implementar con éxito una estrategia de prueba del software se debe tener presente:
|
Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas |
|
Tambien se debe evaluar: portabilidad, facilidad de mantenimiento y facilidad de uso |
|
Establecer los objetivos de la prueba de manera explícita |
|
Se debe establecer: · Objetivos específicos de la prueba · Cobertura de la prueba · Tiempo medio de fallo · El coste para encontrar y arreglar errores · Densidad de fallos remanente o frecuencia de ocurrencia · Horas de trabajo por prueba |
|
Comprender qué usuarios van a manejar el software y desarrollar un perfil para cada categoría de usuario |
|
Se debe: · Describir el escenario de interacción para cada clase de usuario |
|
Desarrollar un plan de prueba que haga hincapié en la “prueba de ciclo rápido” |
|
El equipo de ingeniería de software, debe aprender a probar en ciclos rápidos y que se pueda probar sobre el terreno. |
|
Construir un software “robusto” diseñado para probarse a sí mismo. |
|
El software debe ser capaz de diagnosticar ciertas clases de errores. Además, el diseño debe incluir pruebas automatizadas y pruebas de regresión. |
|
Usar revisiones técnicas formales efectivas como filtro antes de la prueba |
|
Las revisiones técnicas formales ayudan a reducir el esfuerzo de prueba necesaria para la producción del sofware. |
|
Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. |
|
Permiten descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba. |
|
Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba. |
|
Permite usar un enfoque estadístico de control del proceso para la prueba del software. |