Ejemplo de plantilla de plan de pruebas
Equipo editorial
⚡ Resumen inteligente
La plantilla del plan de pruebas recoge la estrategia, el alcance, el cronograma, los entregables y los recursos necesarios para validar la calidad del software. Este documento actúa como un plan maestro que guía todas las actividades de prueba y refuerza la rendición de cuentas en cada versión.
¿Qué es una plantilla de plan de pruebas?
A Plantilla de plan de prueba Es un documento detallado que describe la estrategia de prueba, los objetivos, el cronograma, la estimación, los entregables y los recursos necesarios para las pruebas. Ayuda a determinar el esfuerzo necesario para validar la calidad y sirve como un plan maestro controlado por el gerente de pruebas.
Crear un Plan de prueba es obligatorio para garantizar el éxito de su proyecto de pruebas. Si es nuevo en esto, consulte Cómo crear un plan de prueba.
Descargar plantilla de plan de prueba de muestra
Estructura de la plantilla del plan de pruebas
A continuación se detallan los componentes importantes de una plantilla de plan de pruebas, explicados en orden:
- 1. Introducción
- Alcance 1.1
- 1.1.1 Alcance
- 1.1.2 Fuera de alcance
- 1.2 Objetivo de Calidad
- Roles y Responsabilidades de 1.3
- 2. Metodología de prueba
- Compendio del 2.1
- 2.2 Niveles de prueba
- 2.3 Clasificación de errores
- 2.4 Criterios de suspensión y requisitos de reanudación
- 2.5 Completitud de la prueba
- 3. Entregables de la prueba
- 4. Necesidades de recursos y medio ambiente
- 4.1 Herramientas de prueba
- 4.2 Entorno de prueba
- 5. Términos/Acrónimos
1) Introducción
La introducción ofrece una breve descripción general de las estrategias de prueba, los procesos, el flujo de trabajo y las metodologías utilizadas para el proyecto.
1.1. Alcance
El alcance se divide en dos partes para que los límites de las pruebas permanezcan inequívocos.
1.1.1) En alcance
En Alcance se definen las características, los requisitos funcionales o no funcionales del software que se mantendrá probado
1.1.2) Fuera de alcance
Fuera de alcance define las características, los requisitos funcionales o no funcionales del software que no será probado
1.2) Objetivo de Calidad
Aquí se mencionan los objetivos generales que el equipo planea alcanzar mediante pruebas manuales y pruebas automatizadas. Algunos objetivos de un proyecto de pruebas típico incluyen:
- Asegúrese de que la aplicación bajo prueba (AUT) cumpla con los requisitos funcionales y no funcionales.
- Asegúrese de que la aplicación bajo prueba cumpla con las especificaciones de calidad definidas por el cliente.
- Identificar y corregir errores antes del lanzamiento de la aplicación.
1.3) Funciones y Responsabilidades
Proporcione una descripción detallada de las funciones y responsabilidades de los diferentes miembros del equipo involucrados, tales como:
- Analista de control de calidad
- Test Manager
- Gerente de configuración
- Desarrolladores
- Equipo de instalación
Entre otros.
👉 Inscríbete gratis en el proyecto de pruebas de software en vivo
2) Metodología de prueba
Esta sección determina el ciclo de vida, los niveles y las reglas que rigen la ejecución de las pruebas.
2.1) Resumen
Mencione el motivo para adoptar una metodología de prueba específica para el proyecto. La metodología de prueba seleccionada para el proyecto podría ser:
- Cascada
- Iterativo
- Agil Modelo de
- Programación extrema
La metodología seleccionada depende de múltiples factores. Puede leer más sobre metodología de pruebas. aquí.
2.2) Niveles de prueba
Los niveles de prueba definen los tipos de pruebas que se ejecutarán en la aplicación bajo prueba (AUT).Los niveles elegidos dependen principalmente del alcance del proyecto, el tiempo y las limitaciones presupuestarias.
2.3) Clasificación de errores
El objetivo de la clasificación de errores es:
- Defina el tipo de resolución para cada error.
- Prioriza los errores y establece un cronograma para todos los errores marcados como "Pendientes de corrección".
2.4) Criterios de suspensión y requisitos de reanudación
Los criterios de suspensión definen las condiciones bajo las cuales se detendrá total o parcialmente el procedimiento de prueba. Los criterios de reanudación determinan cuándo se puede reanudar la prueba después de haber sido suspendida.
2.5) Completitud de la prueba
Aquí se definen los criterios que determinarán si la prueba está completa. Por ejemplo, algunos criterios comunes para comprobar la completitud de la prueba serían:
- Se ha logrado una cobertura de pruebas del 100%.
- Se ejecutaron todos los casos de prueba manuales y automatizados.
- Todos los errores detectados se han corregido o están previstos para la próxima versión.
3) Entregables de la prueba
Enumera todos los artefactos producidos a lo largo del ciclo de vida de las pruebas. Registrarlos con antelación evita que se pierdan transferencias entre equipos.
|
4) Necesidades de recursos y medio ambiente
Enumere las herramientas y la infraestructura necesarias para garantizar la seguridad de los presupuestos, las licencias y los entornos antes de que comience la ejecución.
4.1) Herramientas de prueba
Haz una lista de herramientas como:
- Requisitos Tracking
- Error Tracking
- Herramientas de Automatización
Estos elementos son necesarios para probar el proyecto de manera efectiva.
4.2) Entorno de prueba
Menciona el mínimo hardware Requisitos que se utilizarán para probar la aplicación.
Las siguientes software Se requiere además del software específico del cliente:
- Windows 11 y más
- Microsoft 365 (o Office 2021 y versiones posteriores)
- MS Exchange, etc.
5) Términos/Acrónimos
Documente cualquier término o acrónimo utilizado en el proyecto para que los nuevos participantes puedan leer el plan sin ambigüedad.
| TÉRMINO/SIGLA | DEFINICIÓN |
|---|---|
| API | Interfaz del programa de aplicación |
| AUT | Aplicación bajo prueba |
Descargue el formato de plantilla del plan de prueba anterior
Documento de plan de pruebas de ejemplo: Ejemplo de aplicación web bancaria
El siguiente ejemplo resuelto muestra cómo se rellena la plantilla anterior para el GuruAplicación web del Banco 99.
1. Introducción
El Plan de Pruebas prescribe el alcance, el enfoque, los recursos y el cronograma de todas las actividades de prueba para el GuruProyecto del Banco 99. En él se identifican los elementos y características que se van a probar, los tipos de pruebas que se realizarán, el personal responsable y los riesgos asociados al plan.
Alcance 1.1
1.1.1 Alcance
Todas las características del GuruSitio web del banco 99 definido en los requisitos del software especificaciones Es necesario realizar pruebas.
| Nombre del módulo | Roles aplicables | Mareas Ideales para Lecciones |
|---|---|---|
| Consulta de saldo | Gerente de Clientes | Cliente: Un cliente puede tener varias cuentas bancarias y solo puede ver los saldos de sus propias cuentas. Manager: Un gerente puede ver el saldo de todos los clientes bajo su supervisión. |
| Transferencia de fondos | Gerente de Clientes | Cliente: Un cliente puede transferir fondos desde su propia cuenta a cualquier cuenta de destino. Manager: Un gestor puede transferir fondos desde cualquier cuenta de origen a cualquier cuenta de destino. |
| Mini declaración | Gerente de Clientes | Un extracto resumido muestra las últimas 5 transacciones de una cuenta. Cliente: Solo ve el mini-estado de cuenta de sus propias cuentas. Manager: Consulta el mini-estado de cuenta de cualquier cuenta. |
| Declaración personalizada | Gerente de Clientes | Un extracto personalizado filtra y muestra las transacciones de una cuenta por fecha o valor de la transacción. Cliente: Según su propio testimonio. Manager: Cualquier cuenta. |
| Cambiar Contraseña | Gerente de Clientes | Cliente: Puede cambiar la contraseña de su propia cuenta. Manager: Puede cambiar la contraseña de su propia cuenta, pero no la de sus clientes. |
| CLIENTE NUEVO | Manager | Manager: Un gerente puede agregar un nuevo cliente. |
| Editar cliente | Manager | Manager: Puede editar datos como la dirección, el correo electrónico y el teléfono de un cliente. |
| Cuenta nueva | Manager | El sistema ofrece dos tipos de cuenta: de ahorro y corriente. Un cliente puede tener varias cuentas de ahorro (individuales o conjuntas) y varias cuentas corrientes. Manager: Se puede añadir una nueva cuenta para un cliente existente. |
| Editar Cuenta | Manager | Manager: Puede editar los detalles de una cuenta existente. |
| Borrar Cuenta | Manager | Manager: Puede eliminar una cuenta perteneciente a un cliente. |
| Eliminar cliente | Manager | Un cliente solo puede ser eliminado si no tiene cuentas corrientes o de ahorro activas. Manager: Puede eliminar un cliente. |
| Depósitar | Manager | Manager: Se puede depositar dinero en cualquier cuenta, normalmente cuando se deposita efectivo en una sucursal bancaria. |
| Retirar | Manager | Manager: Se puede retirar dinero de cualquier cuenta, normalmente cuando se retira efectivo en una sucursal bancaria. |
1.1.2 Fuera de alcance
Estas características no se prueban porque no forman parte de las especificaciones de requisitos del software:
- Interfaces de usuario
- Interfaces de hardware
- Interfaces de software
- Diseño lógico de la base de datos
- Interfaces de comunicaciones
- Seguridad y rendimiento del sitio web
1.2 Objetivo de Calidad
Los objetivos de la prueba son verificar la funcionalidad de la GuruSitio web de 99 Bank. El proyecto debería centrarse en probar el operaciones bancarias, tales como Administración de cuentas, Retiro y Consulta de saldo, para garantizamos que todas estas operaciones funcionan normalmente en un entorno empresarial real.
Roles y Responsabilidades de 1.3
El proyecto debe utilizar subcontratado miembros como evaluadores para ahorrar en costos del proyecto.
| No. | Miembro | tareas |
|---|---|---|
| 1. | Test Manager | Gestiona todo el proyecto, define su dirección y adquiere los recursos necesarios. |
| 2. | Tester | Identifica y describe las técnicas, herramientas y arquitectura de automatización de pruebas adecuadas; verifica el enfoque de las pruebas; ejecuta las pruebas; registra los resultados; informa sobre los defectos. Miembros subcontratados. |
| 3. | Desarrollador en prueba | Implementa casos de prueba, programas de prueba, conjuntos de pruebas, etc. |
| 4. | Administrador de pruebas | Crea y mantiene el entorno y los recursos de prueba; brinda soporte a los evaluadores durante la ejecución. |
| 5. | Miembros de SQA | Encárgate del control de calidad y confirma si el proceso de pruebas cumple con los requisitos especificados. |
2. Metodología de prueba
Compendio del 2.1
El GuruEl proyecto 99 Bank sigue una metodología de pruebas compatible con Agile, lo que permite a los evaluadores alinearse con los ciclos de desarrollo rápidos al tiempo que mantienen una documentación estructurada.
2.2 Niveles de prueba
En la sección GuruEn el proyecto del Banco 99, se deben realizar tres tipos de pruebas:
- Pruebas de integración: Los módulos de software individuales se combinan y se prueban en conjunto.
- Pruebas del sistema: Realizado en un sistema completo e integrado para evaluar el cumplimiento de los requisitos especificados.
- Prueba de API: Comprueba todas las API expuestas por el software que se está probando.
2.3 Clasificación de errores
Las reuniones de clasificación de errores se llevan a cabo dos veces por semana para clasificar la gravedad del defecto, el responsable y la fecha prevista para la corrección.
2.4 Criterios de suspensión y requisitos de reanudación
If 40% de casos de prueba tienen fracasadoSuspender las pruebas hasta que el equipo de desarrollo solucione todos los casos fallidos.
2.5 Completitud de la prueba
- Especifica los criterios que denotan una exitosos finalización de una fase de prueba.
- Tasa de correr es obligatorio en 100% a menos que se dé una razón clara.
- Tasa de aprobación is 80%; lograr la tasa de aprobación es obligatorio.
2.6 Tareas del proyecto, estimación y cronograma
| Task | Miembros | Esfuerzo estimado |
|---|---|---|
| Crear la especificación de prueba | Diseñador de pruebas | 170 horas-hombre |
| Realizar la ejecución de la prueba | Probador, administrador de pruebas | 80 horas-hombre |
| Informe de prueba | Tester | 10 horas-hombre |
| Entrega de prueba | Test Manager | 20 horas-hombre |
| Total | - | 280 horas-hombre |
Horario: El equipo se compromete a completar estas tareas dentro del plazo acordado para el ciclo de pruebas.
3. Entregables de la prueba
Entregables de prueba para el GuruEl proyecto 99 Bank está organizado en tres fases.
Antes de la fase de pruebas:
- Documento del plan de pruebas.
- Casos de prueba documentos.
- Especificaciones de diseño de la prueba.
Durante la fase de pruebas:
- Simuladores de herramientas de prueba.
- Datos de prueba.
- Prueba tracMatriz de aptitud, registros de errores y registros de ejecución.
Una vez finalizados los ciclos de prueba:
- Resultados e informes de las pruebas.
- Informe de defectos.
- Guía de procedimientos de instalación y prueba.
- Notas de lanzamiento.
4. Necesidades de recursos y medio ambiente
4.1 Herramientas de prueba
| No. | Recursos | Mareas Ideales para Lecciones |
|---|---|---|
| 1. | Server | Un servidor de base de datos en funcionamiento MySQL y un servidor web que ejecuta Apache. |
| 2. | herramienta de prueba | Una herramienta capaz de generar automáticamente los resultados de las pruebas en un formato predefinido y automatizar la ejecución de las mismas. |
| 3. | Network | Una configuración LAN Gigabit y una línea de internet con una velocidad mínima de 5 Mb/s. |
| 4. | Módulo | Al menos 4 estaciones de trabajo en funcionamiento Windows 11, con 8 GB de RAM y un procesador de 3.4 GHz. |
4.2 Entorno de prueba
Esta subsección enumera los requisitos mínimos de hardware y software necesarios para probar la aplicación. Además del software específico del cliente, se requiere el siguiente software:
- Windows 11 y más
- Microsoft 365 (o Office 2021 y versiones posteriores)
- MS Exchange, etc.
Cómo la IA ayuda en la planificación de pruebas
La planificación de pruebas moderna utiliza cada vez más la IA para comprimir el esfuerzo y detectar puntos ciegos. Asistentes generativos como ChatGPT, Claude o Gemini puede elaborar un plan de pruebas inicial a partir de un documento de requisitos, sugerir casos límite faltantes y producir tracMatrices de capacidad automáticamente. Los modelos de aprendizaje automático señalan módulos riesgosos a partir de datos históricos de defectos, ayudan aping El responsable de pruebas centra sus esfuerzos donde más importa.
Sin embargo, la asistencia de la IA no reemplaza el juicio humano. RevLos revisores deben validar el alcance, la cobertura regulatoria y la intención comercial antes de aprobar cualquier plan generado por IA. Considere las sugerencias de la IA como un primer borrador, no como el documento final.
Mejores prácticas para un plan de pruebas eficaz
Un plan de pruebas bien redactado mantiene a todos los interesados alineados. Aplique estas buenas prácticas al elaborar su documento:
- Manténgalo conciso: Utilice un lenguaje claro y listas con viñetas; evite la jerga que pueda dificultar la lectura a personas ajenas al control de calidad.
- Hazlo Reviewable: Compártelo con antelación con los desarrolladores y analistas de negocio para detectar requisitos faltantes.
- Cuantificar los criterios de salida: Defina la cobertura numérica, la tasa de aprobación y los umbrales de defectos.
- Vincular los riesgos con las medidas de mitigación: Acompañe cada riesgo con una estrategia de contención o de respaldo.
- Controla las versiones del plan: Guárdalo en una herramienta de documentación para track cambia a lo largo del proyecto.
