# Plan de Pruebas: [Nombre del Proyecto/Producto] - [Release/Sprint/Ciclo
Específico]
## 1. Introducción
### 1.1. Propósito
Este documento detalla el plan para ejecutar las pruebas del sistema [Nombre del
Proyecto/Producto] para [Release/Sprint/Ciclo Específico, ej: Release 1.2, Sprint
24]. Se basa en la Estrategia de Pruebas general y especifica los ítems a probar,
funcionalidades, enfoque, recursos, planificación y entregables para este ciclo.
### 1.2. Referencias
* Estrategia de Pruebas: [Enlace o Nombre del Documento]
* Requisitos/Historias de Usuario: [Enlace o Referencia]
* Build/Versión Bajo Prueba: [Número de Build/Versión/Commit ID]
## 2. Ítems de Prueba
El componente principal bajo prueba es [Nombre del Componente/Aplicación], versión
[Versión específica].
## 3. Alcance de las Pruebas para este Ciclo
### 3.1. Funcionalidades a Probar
* [Funcionalidad Nueva/Modificada 1] - [Breve descripción o enlace a requisito]
* [Funcionalidad Nueva/Modificada 2]
* [Área de Regresión Crítica 1]
* [Área de Regresión Crítica 2]
* [Referencia a conjunto específico de Casos de Prueba a ejecutar, ej: Casos con
Prioridad Crítica y Alta de test-cases.md]
### 3.2. Funcionalidades que NO se Probarán (en este ciclo)
* [Funcionalidad 1 excluida, ej: Módulo de Administración (será probado en el
próximo ciclo)]
* [Funcionalidad 2 excluida, ej: Pruebas de rendimiento detalladas]
## 4. Enfoque de Pruebas
Para este ciclo, el enfoque principal será [ej: Validar nuevas funcionalidades X e
Y, Realizar regresión completa de las áreas A y B, Ejecutar pruebas de contrato API
para los endpoints modificados]. Se aplicarán las técnicas de [EP, BVA, etc.] según
lo definido en la Estrategia y detallado en los casos de prueba. Se priorizará la
ejecución siguiendo las fases/prioridades definidas en [Referencia, ej: test-
execution-plan.md].
## 5. Entregables de las Pruebas (para este ciclo)
* Resultados de ejecución de los Casos de Prueba [ej: Actualizados en
TestRail/Jira].
* Reportes de Defectos generados durante este ciclo.
* Reporte Resumen de Pruebas específico para [Release/Sprint/Ciclo Específico].
## 6. Entorno de Pruebas (Específico)
* **URL/Acceso:** [URL del entorno QA/Staging]
* **Base de Datos:** [Estado inicial requerido, ej: Reseteada a partir de seed,
Contiene datos específicos del cliente X]
* **Configuración:** [Archivos de configuración específicos a usar, ej: usar
config/products.yml y config/rules.yml por defecto]
* **Credenciales de Acceso:** [Usuario/Contraseña o método de acceso]
* **Herramientas Específicas:** [Versiones concretas si es relevante, ej: Postman
v10.x]
## 7. Datos de Prueba (Específicos)
* **Conjunto de Datos 1:** [Descripción, ej: Productos y reglas estándar
definidos en config/]
* **Conjunto de Datos 2:** [Descripción, ej: Archivos YAML inválidos para pruebas
de error]
* **Conjunto de Datos 3:** [Descripción, ej: Datos específicos para el usuario
'testuser@example.com']
* **Mecanismo de Reseteo:** [ej: Reiniciar el json-server usando `npm start` para
resetear `db.json` desde `db.seed.json`, Limpiar tablas específicas de la BD]
## 8. Planificación y Ejecución
### 8.1. Fases de Ejecución (Adaptado de tu test-execution-plan.md)
* **Fase 1: Pruebas Core / Críticas ([Fechas/Duración Estimada])**
* [Lista de TC-IDs o descripción de áreas, ej: TC-PM-001 a TC-PM-004, TC-DR-
001, TC-DR-004, etc.]
* **Fase 2: Funcionalidad Extendida / Alta Prioridad ([Fechas/Duración
Estimada])**
* [Lista de TC-IDs o descripción de áreas]
* **Fase 3: Configuración / Casos Específicos / Media Prioridad ([Fechas/Duración
Estimada])**
* [Lista de TC-IDs o descripción de áreas]
* **Fase 4: Robustez / Errores / Baja Prioridad ([Fechas/Duración Estimada])**
* [Lista de TC-IDs o descripción de áreas]
* **Fase 5: Pruebas de Regresión Final / Smoke Test ([Fechas/Duración
Estimada])**
### 8.2. Recursos Asignados
* **QA Engineers:** [Nombre(s)]
## 9. Criterios de Entrada/Salida y Suspensión/Reanudación
### 9.1. Criterios de Entrada (para iniciar las fases)
* [ej: Build estable desplegado en el entorno de QA]
* [ej: Requisitos/Historias de Usuario relevantes marcadas como 'Ready for QA']
* [ej: Entorno de pruebas disponible y verificado]
### 9.2. Criterios de Salida/Éxito (para finalizar el ciclo)
* [ej: Todos los casos de prueba Críticos y Altos ejecutados y pasados]
* [ej: Porcentaje mínimo (ej: 95%) de casos de prueba Medios ejecutados y
pasados]
* [ej: No hay defectos Críticos o Altos abiertos sin plan de
mitigación/aplazamiento aprobado]
* [ej: Umbral máximo de defectos Medios/Bajos abiertos]
* [ej: Entrega del Reporte Resumen de Pruebas]
### 9.3. Criterios de Suspensión
* [ej: Defecto Bloqueante Crítico encontrado que impide continuar con >25% de las
pruebas planificadas]
* [ej: Entorno de pruebas inestable o no disponible por > [X] horas/días]
### 9.4. Criterios de Reanudación
* [ej: Defecto bloqueante corregido y verificado]
* [ej: Entorno de pruebas restaurado y estable]
## 10. Gestión de Defectos
* **Herramienta:** [Nombre, ej: Jira]
* **Workflow:** [ej: Open -> In Progress -> Ready for QA ->
Verified/Closed/Reopened]
* **Campos Clave:** [ej: Título, Pasos para Reproducir, Resultado
Esperado/Actual, Severidad, Prioridad, Versión, Entorno]
* **Clasificación de Severidad:**
* **Crítica/Blocker:** Impide pruebas, corrupción de datos, caída del
sistema.
* **Alta/Major:** Funcionalidad principal no operativa o incorrecta.
* **Media/Minor:** Funcionalidad operativa pero con comportamiento inesperado
o incorrecto no crítico.
* **Baja/Trivial:** Problema cosmético, error tipográfico menor.
## 11. Riesgos y Contingencias (para este ciclo)
* **Riesgo 1:** [ej: Retraso en la entrega del build estable] ->
**Contingencia:** [ej: Replanificar fases, enfocar en pruebas independientes]
* **Riesgo 2:** [ej: Descubrimiento de alta densidad de defectos críticos
iniciales] -> **Contingencia:** [ej: Suspender ejecución, solicitar build
corregido, reevaluar planificación]
* **Riesgo 3:** [ej: Falta de datos de prueba específicos] -> **Contingencia:**
[ej: Colaborar con desarrolladores/DBA para generar datos, usar datos simulados si
es posible]
## 12. Aprobaciones
* **Plan de Pruebas Aprobado por:** [Nombre/Rol, ej: QA Lead, Product Owner]
* **Fecha:** [Fecha]
