MÉTODO PARA LA FORMULACIÓN DE LA ESTRATEGIA DE PRUEBA

MÉTODO PARA LA FORMULACIÓN DE LA ESTRATEGIA DE PRUEBA

Algunos autores como Krutchen [7], Pressman [9], Pfleger [11], Cardoso [3] y Sommerville [12] afirman que el

proceso de ejecución de Pruebas debe ser considerado durante todo el ciclo de vida de un proyecto, para así

obtener un producto de alta calidad. Su éxito dependerá del seguimiento de una Estrategia de Prueba adecuada.

La Estrategia de Prueba de software integra un conjunto de actividades que describen los pasos que hay que

llevar a cabo en un proceso de prueba: la planificación, el diseño de casos de prueba, la ejecución y los resultados, tomando en consideración cuánto esfuerzo y recursos se van a requerir, con el fin de obtener como

resultado una correcta construcción del software [9].

La formulación de la Estrategia de Prueba para Software OO (EPSOO) aquí propuesta contempló cinco pasos:

i. Identificación de las Etapas del Proceso de Pruebas,

ii. Propuesta del Instrumento de Medición: Las Listas de Chequeo,

iii. El Diseño y Registro de Casos de Prueba, y

iv. Establecimiento de Pautas para Procesar los Resultados y

v. Diseño Final de la EPSOO.

A continuación se describen estos pasos.

i. Identificación de las Etapas del Proceso de Pruebas: Se inspiró en las Actividades Clásicas del Proceso de

Desarrollo (ACPD), es decir: Análisis, Diseño e Implantación; ya que las mismas se encuentran actualmente

presentes, a manera de disciplinas, en la mayoría de los procesos de desarrollo. Por lo cual, la adopción de estas

etapas no implica necesariamente una secuencialidad en el proceso de desarrollo. Se propone que las pruebas

sean establecidas como un filtro al final de cada ACPD. Para la ACPD de Implantación, las pruebas se

desagregaron en las subactividades de: Unidad, Integración y Sistema. Una vez establecidas las etapas a seguir

durante el proceso de prueba, se procedió a asociar las Técnicas de pruebas para software OO que garantizaran

los RNF. Para identificar los Requerimientos RNF se partió del Modelo de Calidad Sistémica del producto [8].

Este modelo permite identificar las Características de Calidad que deben ser evaluadas en un software. Estas

características tienen a su vez subcaracterísticas asociadas. Se tomaron en cuenta las siguientes características:

Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad.

Por razones de espacio, en la Tabla 1 se muestra el resultado obtenido de la asociación de las técnicas de prueba

con el RNF Fiabilidad a manera de ejemplo.

Tabla 1. Técnicas de prueba al RNF Fiabilidad

Subcaracterística Objetivo Técnicas que aplican

Madurez Evaluar la capacidad que tiene el

software para evitar fallas.

Prueba Negativa: Hacer que el sistema

falle intencionalmente para medir su

capacidad de respuesta frente a un error.

Tolerancia a

Fallas

Verificar la capacidad del software

para mantener un nivel de

rendimiento específico ante un

error, es decir, la capacidad de

continuar procesando en caso de

falla.

Prueba de Valores Límites: Evaluar

valores frontera; es decir, los valores

mínimo y máximo que la unidad puede

aceptar.

Prueba Bajo Stress: Evaluar la

habilidad del sistema para seguir

operando apropiadamente ante bajos

recursos o competencias para los

recursos.

Ejecutar el sistema de manera que

demande recursos en cantidad, frecuencia

o volúmenes anormales.

Prueba Negativa: Hacer que el sistema

falle intencionalmente para medir su

capacidad

...