Universidad Simón Bolívar
Ingeniería de Software 3
Enero-Marzo 2001
 

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.

  2. 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.
     
  3. Alcance

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

  6. 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.
     
  7. Estrategia

  8. 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 fronteras, 60% de los caminos ciclomáticos... La estrategia también explicita el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.
     
  9. Categorización de la configuración

  10. Explicita las condiciones bajo las cuales, el plan debe ser: En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba debe suspenderse en vista de los defectos o fallas que se han detectado.  Al corregirse los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas pruebas. Los criterios de culminación pueden ser tan simples como aprobar el número mínimo de  casos de prueba diseñados o tan complejo como tomar en cuenta no sólo el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de detección de fallas.
     
  11. Tangibles

  12. Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej. subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso y bitácora de pruebas.
     
  13. Procedimientos especiales

  14. Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.
     
  15. Recursos

  16. Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas (p. ej. el sistema de operación), cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar (p. ej. qué módulos se colocan en qué máquinas de una red local) y la configuración del software de apoyo.

    La sección incluye un estimado de los recursos humanos necesarios para el proceso. También se indican cualquier requerimiento especial del proceso: actualización de licencias, espacio de oficina, tiempo en la máquina de producción, seguridad.
     

  17. Calendario

  18. Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar.
     
  19. Manejo de riesgos

  20. Explicita los riesgos del plan, las acciones mitigantes y de contigencia.
     
  21. Responsables

  22. Especifica quién es el responsable de cada una de las tareas previstas en el plan.
La dirección del proceso de pruebas es parte de las responsabilidades del Coordinador de Calidad, figura nueva a introducirse este trimestre en el proyecto Delta Pensum.

Note que, en el proceso adoptado para Delta Pensum, algunos de los renglones del Plan de Pruebas, pueden detallarse en la descripción de las Suites de Prueba. Recuerde que es importante evitar información redundante.
 

Referencias

Próximos tópicos

Tópicos previos


Esta página fue creada el 4 de enero de 2001.
Ultima actualización: 20 de enero de 2001.
Por favor dirija sus comentarios al Prof. Alejandro Teruel.