¿Qué es un plan de pruebas?
Un plan de pruebas es un documento detallado que describe la estrategia, los objetivos, los recursos, el cronograma y el alcance de un esfuerzo de pruebas. Es el plano de toda la fase de QA: responde quién prueba qué, cómo, cuándo y qué aspecto tiene "terminado".
Considera un plan de pruebas como un contrato entre el equipo de QA, los desarrolladores y las partes interesadas. Establece expectativas, define responsabilidades y proporciona una hoja de ruta para la ejecución de las pruebas. Tanto si pruebas un sitio web pequeño como una gran aplicación empresarial, un buen plan de pruebas mantiene a todos alineados.
Este artículo proporciona una plantilla de plan de pruebas gratuita y lista para copiar y pegar, con un ejemplo del mundo real, para que puedas crear tu propio plan de pruebas en minutos.
Plantilla de plan de pruebas (lista para copiar y pegar)
A continuación se presenta una plantilla completa de plan de pruebas. Cópiala en tu documento, hoja de cálculo o herramienta de gestión de proyectos y personalízala para tu proyecto.
Plan de pruebas
=========
### 1. Introducción
1.1 Propósito
[Breve descripción de por qué existe este plan de pruebas]
1.2 Alcance
[Qué se está probando: incluye funciones, módulos, sistemas]
1.3 Fuera de alcance
[Qué NO se está probando: sé explícito]
1.4 Referencias
[Enlaces a documentos de requisitos, especificaciones de diseño, historias de usuario]
### 2. Objetivos de las pruebas
[Lo que quieres lograr con las pruebas. Ejemplos:]
- Verificar que todos los flujos de trabajo empresariales críticos funcionan correctamente
- Garantizar la compatibilidad entre navegadores (Chrome, Firefox, Safari, Edge)
- Validar la integridad de los datos en todas las operaciones CRUD
- Alcanzar una tasa de aprobación de casos de prueba ≥ 95% antes de la firme
### 3. Estrategia de pruebas
3.1 Niveles de prueba
[ ] Pruebas unitarias
[ ] Pruebas de integración (SIT)
[ ] Pruebas de sistema
[ ] Pruebas de aceptación del usuario (UAT)
3.2 Tipos de pruebas
[ ] Pruebas funcionales
[ ] Pruebas de regresión
[ ] Pruebas de rendimiento
[ ] Pruebas de seguridad
[ ] Pruebas de usabilidad
[ ] Pruebas de accesibilidad
3.3 Entorno de pruebas
- URL de staging: [https://staging.example.com]
- Base de datos: [PostgreSQL 15, réplica de staging]
- Navegadores objetivo: [Chrome 125+, Firefox 125+, Safari 17+, Edge 125+]
- Dispositivos móviles objetivo: [iOS 17+, Android 14+]
- Herramientas de prueba: [BugCapturer, Lighthouse, axe DevTools]
### 4. Entregables de las pruebas
[ ] Documento del plan de pruebas (este documento)
[ ] Especificaciones de casos de prueba
[ ] Datos de prueba (cuentas ficticias, contenido de muestra)
[ ] Informes de bugs (registrados durante la ejecución)
[ ] Informe de ejecución de pruebas (resumen de aprobado/fallido)
[ ] Documento de firme de la UAT
### 5. Cronograma de pruebas
| Fase | Fecha de inicio | Fecha de finalización | Duración |
|-------|------------|----------|----------|
| Planificación de pruebas | [Fecha] | [Fecha] | [X días] |
| Preparación de casos de prueba | [Fecha] | [Fecha] | [X días] |
| Ejecución de pruebas (ronda 1) | [Fecha] | [Fecha] | [X días] |
| Corrección de bugs | [Fecha] | [Fecha] | [X días] |
| Ejecución de pruebas (ronda 2) | [Fecha] | [Fecha] | [X días] |
| UAT | [Fecha] | [Fecha] | [X días] |
| Firme | [Fecha] | [Fecha] | [X días] |
### 6. Roles y responsabilidades
| Rol | Nombre | Responsabilidades |
|------|------|-----------------|
| Gerente de pruebas | [Nombre] | Planificar, coordinar, informar |
| Ingeniero de QA | [Nombre] | Escribir casos de prueba, ejecutar pruebas, registrar bugs |
| Desarrollador | [Nombre] | Corregir bugs, apoyar la resolución de problemas |
| Propietario de producto | [Nombre] | Definir los criterios de aceptación, firme de la UAT |
| Participantes de la UAT | [Nombres] | Ejecutar los escenarios de la UAT |
### 7. Resumen de casos de prueba
| Módulo | Total de casos de prueba | Automatización % | Prioridad |
|--------|-----------------|--------------|----------|
| Registro de usuario | [XX] | [X%] | Alta |
| Inicio de sesión / Autenticación | [XX] | [X%] | Alta |
| Pago | [XX] | [X%] | Crítica |
| Búsqueda | [XX] | [X%] | Media |
| Panel de administración | [XX] | [X%] | Baja |
### 8. Proceso de seguimiento de bugs
1. El evaluador encuentra un bug
2. El evaluador registra un informe de bugs con:
- Captura de pantalla o grabación de pantalla (anotada)
- Pasos para reproducir
- Detalles del entorno (URL, navegador, SO)
- Resultado esperado frente al real
3. El gerente de pruebas clasifica y asigna la prioridad
4. El desarrollador corrige el bug
5. El evaluador verifica la corrección
6. El bug se cierra
Herramienta recomendada: BugCapturer para informes de bugs en un clic
con metadatos capturados automáticamente y capturas de pantalla anotadas.
### 9. Criterios de entrada y salida
9.1 Criterios de entrada (qué debe ser cierto antes de que empiecen las pruebas)
[ ] Todas las funciones críticas están desarrolladas
[ ] El entorno de staging es estable
[ ] Los datos de prueba están preparados
[ ] Los casos de prueba están revisados y aprobados
9.2 Criterios de salida (qué debe ser cierto antes de que terminen las pruebas)
[ ] Todos los bugs críticos y de alta prioridad están corregidos
[ ] El 95% de los casos de prueba aprobaron
[ ] La UAT está firmada por las partes interesadas
[ ] Se cumplen los objetivos de rendimiento
### 10. Riesgos y mitigación
| Riesgo | Impacto | Probabilidad | Mitigación |
|------|--------|-------------|------------|
| Entorno de staging inestable | Alto | Media | Tener un plan de reversión, entorno de respaldo |
| Cambios en APIs de terceros | Medio | Media | Simular los servicios externos desde el principio |
| Disponibilidad limitada de participantes de UAT | Alto | Baja | Reclutar evaluadores de respaldo, ampliar la ventana de UAT |
| Expansión del alcance | Medio | Alta | Congelar los requisitos antes de que empiecen las pruebas |
### 11. Aprobaciones
| Rol | Nombre | Firma | Fecha |
|------|------|-----------|------|
| Gerente de pruebas | [Nombre] | | |
| Gerente de proyecto | [Nombre] | | |
| Propietario de producto | [Nombre] | | |
Ejemplo de plan de pruebas
Aquí tienes un ejemplo de plan de pruebas cumplimentado para el lanzamiento de un sitio web de comercio electrónico:
Proyecto: Lanzamiento de AcmeShop.com v2.0 Gerente de pruebas: Alex Wang Cronograma: 4 semanas (2 semanas de ejecución + 1 semana de corrección de bugs + 1 semana de UAT)
Alcance:
- Registro de usuario, inicio de sesión, restablecimiento de contraseña
- Exploración de productos, búsqueda, filtrado
- Carrito de la compra y pago
- Historial de pedidos y seguimiento
- Gestión de pedidos del administrador
- Integración de la pasarela de pago (Stripe)
Fuera de alcance:
- Sistema de gestión de inventario de terceros (proveedor aparte)
- Validación de datos de migración de la versión heredada v1.0
- Pruebas de carga más allá de 1.000 usuarios concurrentes
Resumen de casos de prueba:
- Total: 245 casos de prueba (85 automatizados, 160 manuales)
- Módulos: Autenticación (32), Productos (48), Carrito (55), Pago (70), Administración (40)
- Tasa de aprobación esperada: 95% antes de la UAT, 98% antes del lanzamiento
Riesgos clave:
- El sandbox de la API de Stripe se comporta de forma distinta a producción: mitigado añadiendo casos de prueba adicionales para los casos límite
- Los participantes de la UAT son miembros del equipo de ventas con disponibilidad limitada: se reclutaron 10 participantes, con la intención de tener 5 activos
Seguimiento de bugs:
- Uso de BugCapturer para todos los informes de bugs
- Bugs críticos: corregir en 4 horas, volver a probar inmediatamente
- Bugs altos: corregir en 24 horas, volver a probar el mismo día
- Bugs medios: corregir antes del lanzamiento
- Bugs bajos: acumulados para después del lanzamiento
Plan de pruebas de muestra: secciones clave explicadas
Objetivos de las pruebas
Esta es la sección más importante. Responde a "¿por qué probamos?". Unos buenos objetivos son específicos y medibles:- ❌ "Probar el sitio web a fondo"
- ✅ "Verificar que los 20 flujos de pago se completan sin errores en Chrome, Firefox, Safari y Edge"
Criterios de entrada y salida
Los criterios de entrada evitan el esfuerzo desperdiciado (no empezar las pruebas sobre una compilación rota). Los criterios de salida evitan la firme prematura (no dar por terminadas las pruebas cuando aún hay bugs críticos abiertos).Proceso de seguimiento de bugs
Un proceso claro de seguimiento de bugs es esencial para una fase de ejecución de pruebas fluida. Cuanto más rápido se informan los bugs, más rápido se corrigen. Usar una herramienta como BugCapturer durante la ejecución de las pruebas acelera el bucle de retroalimentación:- Anotación de capturas de pantalla — los evaluadores pueden resaltar los problemas directamente en la página con flechas, rectángulos y texto
- Metadatos técnicos automáticos — la URL, el navegador, el SO, la resolución de pantalla y el viewport se capturan automáticamente
- Grabación de pantalla — graba un video WebM breve del bug y luego recorta y extrae los fotogramas clave
- Recopilación de datos de diagnóstico — los errores de consola y las solicitudes de red fallidas se capturan junto con la evidencia visual
- Exportación a Excel/TSV — copia en un clic una fila de informe de bugs estructurada a tu portapapeles para el seguimiento del equipo
Cómo crear un plan de pruebas
Paso 1: Comprende el proyecto
Lee los requisitos, habla con las partes interesadas y comprende qué se está construyendo. Un plan de pruebas es tan bueno como tu comprensión del proyecto.Paso 2: Define el alcance
Sé explícito sobre lo que está dentro y fuera del alcance. Un alcance vago es la causa nº 1 de disputas sobre el plan de pruebas.Paso 3: Elige tu estrategia
Decide qué niveles y tipos de pruebas se aplican a tu proyecto. Un sitio de marketing pequeño necesita pruebas diferentes a las de una aplicación bancaria.Paso 4: Estima los recursos y el cronograma
Usa datos históricos de proyectos anteriores. Si no tienes datos históricos, añade un margen del 30% a tus estimaciones.Paso 5: Escribe el plan
Usa la plantilla anterior. Empieza con la plantilla y luego personalízala. No lo escribas desde cero.Paso 6: Obtén las aprobaciones
Un plan de pruebas que nadie firmó es un plan de pruebas que nadie sigue. Obtén la aprobación por escrito del gerente de proyecto y del propietario de producto.Descarga: plantilla de plan de pruebas
La plantilla anterior funciona en cualquier formato:
- Google Docs / Word — usa la estructura de secciones como documento formal
- Confluence / Notion — crea una página de plan de pruebas con subpáginas para cada sección
- Excel / Google Sheets — usa una hoja de cálculo con pestañas para cada fase
- Markdown — consérvala en tu repositorio para el control de versiones
Elige el formato que usa tu equipo. El formato importa menos que el contenido: un buen plan de pruebas en un documento sencillo supera a un mal plan de pruebas en una herramienta sofisticada.