Este documento describe las estrategias clave para probar software de manera efectiva. Explica que la prueba de software debe realizarse en tres niveles: pruebas de unidad para cada módulo, pruebas de integración para integrar los módulos, y pruebas de validación para verificar que el software cumple con los requisitos del cliente. También destaca la importancia de definir objetivos de prueba medibles, realizar revisiones técnicas antes de la prueba, e implementar un enfoque de mejora continua para el proceso de p

1. ENFOQUE ESTRATÉGICO PARA LA
PRUEBA DE SOFTWARE
Jorge Bustillos
Gestión de Calidad del Software

2. Contenido
• Pruebas de software.
• Características de estrategias de prueba.
▫ Verificación y Validación.
▫ Organización para la prueba de software.
▫ Estrategias de prueba de software
Estrategias.
▫ Criterios para completar la prueba.
Prueba de Unidad.
Prueba de Integración.
Prueba de Validación.

3. Pruebas de software.
• 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.

4. Características estrategia de prueba
• Las pruebas comienzan 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

5. 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?

6. ORGANIZACIÓN PARA LA PRUEBA DE
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
desintegración.
▫ Cuando se tiene una arquitectura completa de
software, los encargados dela prueba es un Grupo
Independiente de Prueba (GIP), permitiendo que
se tenga independencia.

7. ESTRATEGIA DE PRUEBA DE SOFTWARE
• Los niveles de la estrategia para la prueba del
software:

8. • 1.La prueba se centra en cada
módulo individualmente,
asegurando que funcionan
adecuadamente como una unidad.
• 2.Se ensamblan o integran los
módulos para formar el paquete de
software completo.
• 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.
• 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.

9. Estrategias
• Especificar los requisitos del producto de manera
cuantificable mucho antes de que comiencen las pruebas
• Establecer los objetivos de la prueba de manera explícita
▫ 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
▫ 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”

10. • Construir un software “robusto” diseñado para probarse
a sí mismo.
▫ 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
software.
▫ Llevar a cabo revisiones técnicas formales para evaluar la
estrategia de prueba y los propios casos de 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

11. CRITERIOS PARA COMPLETAR LA
PRUEBA
• El proceso de verificación, se centra en la menor
unidad del diseño del software: clases y objetos.
• Está orientada a caja blanca y este paso se puede
llevar a cabo en paralelo para múltiples
módulos.

12. Prueba de Unidad

13. Prueba de integración
• Asegurar que los distintos objetos y clases funcionen adecuadamente en
conjunto.
• La mejor forma de aplicar una prueba de integración, está aplicando un
enfoque incremental, es decir, ir integrando los módulos poco a poco, con lo
cual podemos aislar la detección de errores.
• Un enfoque no incremental como lo es el enfoque “big bang”, consiste en
integrar todos los módulos y una vez juntos probar el sistema esperando la
explosión de errores que se puede generar.
• La prueba de integración puede llevarse a efecto de diferentes formas
▫ Integración descendente
▫ Integración ascendente
▫ Por regresión.

14. Prueba de validación
• Dentro de esta prueba debemos entender por validación
a la verificación del funcionamiento del software de
acuerdo a los requerimientos del cliente.
• El resultado de esta prueba es crucial dado que si el
software no cumple con las expectativas del cliente, todo
el esfuerzo y trabajo no tendrán ningún significado y
aunque pudiera verse como una prueba arbitraria no es
así, ya que solamente si no hemos implementado los
mecanismos de calidad necesarios en el proceso de
desarrollo está prueba no tendría que modificar aspectos
estructurales del software sino solamente a aspectos
superficiales y de interfaces.