Ejemplo de plantilla de plan de pruebas

¿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:

• Herramienta de seguimiento de requisitos
• Herramienta de seguimiento de errores
• 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.

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 práctico muestra cómo se rellena la plantilla anterior para la aplicación web del banco Guru99.

1. Introducción

El Plan de Pruebas define el alcance, el enfoque, los recursos y el cronograma de todas las actividades de prueba del proyecto Guru99 Bank. En él se identifican los elementos y las funcionalidades que se probarán, 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 sitio web de Guru99 Bank definidas en los requisitos del software especificaciones Es necesario realizar pruebas.

Nombre del módulo	Roles aplicables	Descripción
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 del sitio web del Banco Guru99. El proyecto debe centrarse en probar la 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 proyecto Guru99 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 el proyecto Guru99 Bank, 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

Schedule: El equipo se compromete a completar estas tareas dentro del plazo acordado para el ciclo de pruebas.

3. Entregables de la prueba

Los entregables de prueba para el proyecto Guru99 Bank están organizados 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.
• Matriz de trazabilidad de pruebas, 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	Descripción
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 generar matrices de trazabilidad automáticamente. Los modelos de aprendizaje automático identifican módulos de riesgo a partir de datos históricos de defectos, lo que ayuda al gestor de pruebas a concentrar 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 realizar un seguimiento de los cambios en todo el proyecto.

Preguntas Frecuentes