El módulo del plan de pruebas es un instrumento muy útil para dar estructura tanto al proceso de pruebas como a la documentación de las mismas es el plan de pruebas.[2]
Algunos aspectos que se deben contemplar para un plan de pruebas son los siguientes:
2) Alcance: Indica el tipo de prueba y las propiedades o elementos del software a ser probado.
3) Items por 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 difícil 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 o herramienta que se pueda utilizar en el diseño de los casos de prueba. Como 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 pre-condición". En lo posible la estrategia debe precisar el número mínimo de casos de prueba a diseñar. La estrategia también explica el grado de automatización que se exigirá, tanto para la generación de casos de prueba como para su ejecución.
5) Caracterización de la configuración: Hace de forna explícita las condiciones bajo las cuales, el plan debe ser suspendido-repetido-culminado.
En algunas circunstancias 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 explicarse a partir de qué punto, ya que puede 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.
6) Tangibles: En este caso los documentos a entregarse al culminar el proceso previsto por el plan deben estar de la mayor forma posible bien estructurados.
7) Procedimientos especiales: Identifica el grado de las tareas necesarias para preparar y ejecutar las pruebas, así como cualquier habilidad especial que se requiere.
8) Recursos: Se deben identificar las propiedades necesarias y deseables del ambiente de prueba, incluyendo las características del hardware, el software de sistemas. Cualquier otro software necesario para llevar a cabo las pruebas, así como la colocación específica del software a probar.
9) Calendarios: Esta parte describe los hitos del proceso de prueba y el grafo de dependencia en el tiempo de las tareas a realizar. Se puede realizar con diagramas como el diagrama de Gantt.
10) Manejo de riesgos: Identifica los riesgos en el plan, las acciones que lo solucionan y la contingencia de estos.
11) Responsables: Especifica quién es el responsable de cada una de las tareas previstas en el plan.[1]
Plan de Pruebas - IEEE 829
La estructura de un plan de pruebas en este tipo de estándar es el siguiente:
1- Introducción
2-Items de pruebas
3-Supuestos
4-Características sujetas a pruebas
5-Características No sujetas a pruebas
6-Estrategia de prueba
7-Criterios de éxito/fracaso
8-Criterios de suspensión/devolución
9-Entregables de las pruebas
10-Tareas de la etapa de prueba
11-Recursos:
Recursos hardware
Recursos software
Herramientas de soporte
12) Roles y responsabilidades
13) Riesgos del proyecto de pruebas
14) Dotación de personal y formación
15)Cronograma/Calendario.
16)Aprobación
Referencias:
[1] Obtenido de: http://www.calidadysoftware.com/testing.php
[2] Obtenido de: http://www.pruebasdesoftware.com/plandeprueba.htm
No hay comentarios:
Publicar un comentario