Plan De Pruebas

Cd. Nanchital, Ver., a 09 de Marzo 2012

El Plan de Pruebas

IEEE 829-1983

El estándar IEEE 829-1983 describe los tipos de documentos que pueden producirse durante el proceso de prueba. Puede resultar interesante comparar nuestra propuesta con el estándar. Recuerde que sólo hemos visto los tipos de documentos asociados a la prueba de procedimientos.

Delta Pensum IEEE 829-1983

Plan de pruebas de un requerimiento Plan de prueba

(opcional) Tabla de decisiones asociada al requerimiento

Análisis de verificabilidad del requerimiento

Criterio de verificación

Requisitos de observabilidad

Requisitos de controlabilidad

Pistas

Catálogo de modelos de defectos

Requerimientos de prueba Especificación de los requerimientos para el diseño de los casos de prueba

Suite de prueba

Caso de prueba Caso de prueba

Descripción del procedimiento de prueba

Descripción del item a probar (IUT en Binder)

Ambiente de prueba

Bitácora de pruebas Bitácora de pruebas

Reporte de incidentes de prueba

Análisis de resultados y acciones recomendadas

Resumen gerencial del proceso Resumen de pruebas

El Plan de Pruebas

El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.

Note que puede haber un plan global que explicite el énfasis a realizar sobre los distintos tipos de pruebas (verificación, integración e integración).

Un plan de pruebas incluye:

1. Identificador del plan.

Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance, por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse adicionalmente la versión y fecha del plan.

2. Alcance

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Items a probar

Indica la configuración a probar y las condiciones mínimas que debe cumplir para comenzar a aplicarle el plan. Por un lado, es dificil y riesgoso probar una configuración que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia

Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej. 100% de las

...