🧪 PLAN DE PRUEBAS (TEST PLAN)
📋 Información General
| Campo | Detalle | Campo | Detalle |
|---|---|---|---|
| Proyecto: | [Nombre del Proyecto] | Código Proyecto: | [codigo] |
| Celula/Equipo: | [Nombre] | Sprint/Release: | [Nombre Sprint o version] |
| Fecha inicio pruebas | [dd/mm/aaaa] | Fecha fin pruebas: | [dd/mm/aaaa] |
| Ambiente: | [QA / UAT / Stage] | QA Responsable: | [Nombre del QA] |
1. Introducción
Este documento describe el Plan de Pruebas del proyecto, ejecutado bajo el marco Scrum y alineado al Marco Metodológico de Aseguramiento de Calidad (QA).
Su propósito es definir la estrategia, alcance, criterios y controles necesarios para validar que las funcionalidades desarrolladas cumplen con los requisitos definidos y no impactan negativamente componentes existentes.
🎯 Propósito visual del Plan de Pruebas
2. Alcance de las pruebas
2.1 Funciones a probar
[HU / Funcionalidad 1][HU / Funcionalidad 2][HU / Funcionalidad 3]
2.2 Funciones fuera de alcance
- Funcionalidades no incluidas en el Sprint.
- Integraciones externas no contempladas.
- Módulos no impactados por el cambio.
2.3 Roles y Responsabilidades:
- Scrum Master: Facilita el proceso de pruebas y asegura que el equipo siga la metodología Scrum.
- Equipo de Desarrollo: Responsable de implementar y realizar pruebas unitarias.
- Equipo de QA: Responsable de diseñar, ejecutar pruebas de integración, sistema y UAT.
- Product Owner: Valida los resultados de las pruebas de aceptación del usuario.
👥 Mapa visual de responsabilidades
2.4 Actividades de Pruebas:
- Diseño de plan de pruebas
- Análisis y diseño de casos de prueba.
- Gestión de datos de prueba.
- Revisión de cobertura de los casos de prueba.
- Ejecución de pruebas.
- Reporte y seguimiento de defectos
- Evidencia y documentación de resultados de prueba.
- Envío de reporte de estatus de pruebas(Plan de pruebas).
- Peer review de artefactos.
2.5 Revisiones diarias:
- Estatus de ejecución de pruebas en sesiones de Daily.
- Dashboard de QA
3. Estrategia de pruebas
3.1 Enfoque
- Testing basado en riesgo.
- Validación incremental por historia.
- Ejecución priorizada por criticidad.
- Automatización progresiva cuando aplique.
- Evidencia obligatoria en herramienta oficial.
🚦 Enfoque de ejecución
3.2 Niveles de pruebas
| Nivel | Objetivo | Responsable |
|---|---|---|
| Unitarias | Validar componentes individuales | Desarrollo |
| Integración | Validar interacción entre módulos | Dev / QA |
| Sistema | Validar sistema completo | QA |
| Regresión | Validar que cambios no impacten funcionalidades existentes | QA |
| Re-test | Validar corrección de defectos | QA |
| Smoke | Validar estabilidad post despliegue | QA |
| UAT | Validación funcional del negocio | PO / Cliente |
🧪 Vista visual de niveles
3.3 Pruebas manuales
| Nivel | Descripción | ¿Aplica? [Sí/No] |
|---|---|---|
| Unitarias | Validación de componentes individuales | |
| Integración | Validación entre módulos | |
| Sistema | Validación flujo completo | |
| UAT | Validación funcional del negocio | |
| Regresión | Validación funcionalidades existentes | |
| Smoke | Validación rápida post despliegue | |
| Exploratorias | Pruebas no estructuradas | |
| Re-test | Validación de corrección de defectos |
3.4 Pruebas No funcionales
| Tipo | Clasificación [Manual / Automática] | ¿Aplica? [Sí/No] |
|---|---|---|
| Seguridad | Validar protección ante vulnerabilidades | |
| Performance – Carga | Este tipo de prueba se enfoca en evaluar cómo se comporta una aplicación web cuando está sometida a un nivel específico de carga. | |
| Performance – Estrés | Este tipo de prueba se enfoca en evaluar la capacidad de la aplicación web para manejar cargas de trabajo extremas o inesperadas, que van más allá de lo que se espera en una situación normal. | |
| Estabilidad | Las pruebas de volumetría son un tipo de prueba de carga que se utiliza para medir la capacidad de una aplicación para manejar grandes cantidades de datos o transacciones. La prueba de volumetría ayuda a determinar el punto en el que la aplicación alcanza su capacidad máxima para manejar una carga de trabajo específica. |
⚙️ Mapa de pruebas No funcionales
3.5 Pruebas automatizadas
| Tipo de prueba | Descrip | ¿Aplica? [Sí/No] |
|---|---|---|
| Automatizadas | Consisten en la aplicación de herramientas de software para automatizar el proceso manual de revisión y validación de un producto de software que lleva a cabo una persona. |
Descripción de estrategia de automatización
- Herramienta utilizada:
[Tricentis, Cypress / Selenium / etc.] - Cobertura esperada:
[%] - Flujos críticos automatizados:
[Detalle]- Cp1---
4. Ambiente de Pruebas
4.1 Hardware
- Servidor de pruebas:
[Especificación] - Equipos usuario:
[Especificación]
4.2 Software
- Sistema operativo:
[Detalle] - Base de datos:
[Detalle] - Herramientas de pruebas:
[Azure Devops]
4.3 Navegadores y dispositivos móviles
[Chrome][Edge][Firefox][Safari]- Dispositivos móviles:
[Versiones]
4.4 Diagrama de arquitectura
[Adjuntar o referenciar documento de ambiente]
🏗️ Espacio para arquitectura El documento solicita **adjuntar o
referenciar el documento de ambiente**. Cuando se cuente con la arquitectura real, este bloque puede sustituirse o complementarse con un diagrama Mermaid, C4 o una imagen referenciada desde Docusaurus. :::
5. Gestión de Defectos y Mejoras
5.1 Clasificación de Defecto / Mejora
🐞 Defecto:
Incumplimiento de un requisito, historia de usuario o criterio de aceptación definido.
Implica desviación funcional, técnica o de desempeño respecto a lo especificado.
💡 Mejora:
Propuesta de optimización, ajuste o valor agregado no contemplado originalmente en la Historia de Usuario o requerimiento aprobado.
6 Criterios de Suspensión y Reanudación
6.1 Criterios de Suspensión
Las pruebas podrán suspenderse cuando ocurra alguna de las siguientes condiciones:
- Defectos críticos bloqueantes que impidan la continuidad del flujo principal.
- Ambiente de pruebas inestable o no disponible.
- Fallo masivo del sistema que afecte múltiples funcionalidades.
- Ausencia de datos de prueba esenciales.
- Build con defectos estructurales que impidan ejecución controlada.
⛔ Suspensión de pruebas Las pruebas podrán suspenderse ante
defectos críticos bloqueantes, inestabilidad del ambiente, fallos masivos, ausencia de datos esenciales o un build con defectos estructurales. :::
6.2 Criterios de Reanudación
Las pruebas podrán reanudarse cuando:
- Los defectos críticos hayan sido corregidos y validados en re-test.
- El ambiente de pruebas se encuentre estable y validado.
- Los datos de prueba estén completos y consistentes.
- Exista autorización formal del QA Lead (cuando aplique) o responsable designado.
▶️ Reanudación de pruebas