Un plan de prueba sin una sección de fuera de alcance es un documento que dice "sí" a todo por defecto: cada stakeholder asume que su funcionalidad está cubierta, y el equipo nunca llega a un punto de fin definido. Un plan de una página que la gente realmente lee y consulta durante el testing vale más que un documento de 20 páginas archivado antes de que empiece el sprint. Esta guía cubre las secciones que un plan de prueba realmente necesita, con ejemplos reales para cada una en lugar de placeholders abstractos, incluyendo alcance, evaluación de riesgos, criterios de entrada y salida, y un mini plan completo para una funcionalidad pequeña.

Qué es (y qué no es) un plan de prueba

Es

Un documento que define el alcance, el enfoque y los recursos para testear una funcionalidad o release, comunicación entre QA, desarrolladores y stakeholders, y una referencia durante el testing para que todos sepan qué se supone que debía ocurrir.

No es

Una lista de casos de prueba (ese es un documento diferente), una garantía de que no van a salir bugs a producción, ni algo que necesite 40 páginas.

Un plan de una página para una funcionalidad pequeña es completamente apropiado. El objetivo es la claridad, no la extensión.

Las secciones principales

1. Funcionalidad o sistema bajo prueba

¿Qué estamos testeando exactamente? Sé específico.

Vago

Testear el proceso de checkout

Específico

Testear el flujo de checkout para usuarios registrados: carrito → dirección de envío → pago (Stripe) → confirmación de orden. Excluye checkout de invitados (testeado por separado) y devoluciones (todavía no implementadas).

2. Objetivos y metas

¿Qué queremos lograr con este esfuerzo de testing?

Ejemplo

- Verificar que los usuarios registrados pueden completar compras de productos físicos
- Asegurar que el procesamiento de pagos se integra correctamente con Stripe en escenarios de éxito y rechazo
- Confirmar que los emails de confirmación de orden se envían dentro de los 2 minutos de la compra
- Validar que el inventario se descuenta correctamente después de la compra

3. Alcance

Dentro del alcance

  • Registro e inicio de sesión de usuarios
  • Agregar ítems al carrito
  • Aplicar códigos de descuento
  • Checkout con tarjeta de crédito
  • Página de confirmación de orden
  • Email de confirmación de orden

Fuera del alcance

  • Integración con PayPal (Fase 2)
  • Checkout de invitados (funcionalidad separada)
  • Devoluciones y reembolsos
  • App mobile (plan de prueba separado)

Esta es la sección más importante que hay que escribir con cuidado. El scope creep en testing es tan real como en el desarrollo.

4. Enfoque de testing

¿Cómo se va a realizar el testing?

Ejemplo

| Tipo | Enfoque | Quién |

|------|---------|-------|

| Smoke testing | Manual, antes de regresión | Equipo QA |

| Testing funcional | Casos de prueba manuales | Equipo QA |

| Testing de API | Automatizado con Playwright | QA automation |

| Regresión E2E | Automatizado con Playwright | QA automation |

| Performance | Load test con k6 | DevOps |

| Exploratorio | Sesión de 2 horas por sprint | Equipo QA |

5. Entorno de prueba

¿Dónde va a ocurrir el testing?

Entorno: Staging (https://staging.miapp.com)
Datos: Base de datos de staging nueva con datos de prueba
Navegador: Chrome (principal), Firefox (regresión)
Mobile: iOS Safari via BrowserStack (solo smoke)

Credenciales API: Claves de modo test de Stripe
Tarjeta de test Stripe: 4242 4242 4242 4242
Tarjeta rechazada: 4000 0000 0000 0002

6. Datos de prueba

¿Qué datos deben existir antes de que empiece el testing?

Usuarios

  • 3 usuarios registrados con diferentes roles (admin, member, viewer)
  • 1 usuario con método de pago guardado
  • 1 usuario con método de pago vencido
  • Caso límite: usuario con nombre muy largo (para testear truncamiento de formulario)

Productos

  • Producto estándar (en stock)
  • Producto sin stock
  • Producto con código de descuento aplicado
  • Producto digital (no requiere envío)

Códigos de descuento

SAVE10 (10% de descuento, activo), SAVE50 (50% de descuento, activo) y EXPIRED99 (vencido, no debe aplicarse).

7. Evaluación de riesgos

¿Cuáles son las áreas más riesgosas? ¿Qué podría salir mal?

| Riesgo | Probabilidad | Impacto | Mitigación |

|--------|-------------|---------|------------|

| Falla en la integración con Stripe | Media | Alto | Testear con modo test de Stripe; tener opción de pago alternativa |

| Race condition en inventario | Baja | Alto | Testear compras concurrentes del mismo ítem |

| Demora en entrega de email | Media | Medio | Buffer de 5 minutos en tests; revisar logs del proveedor de email |

| Bypass de código de descuento | Baja | Alto | Sesión exploratoria enfocada en seguridad |

| Errores de redondeo de precios | Baja | Alto | Testear con precios que producen resultados .999 |

Mayor riesgo = más cobertura de tests necesaria.

8. Criterios de entrada y salida

Criterios de entrada (el testing puede empezar cuando):
  • Todas las funcionalidades dentro del alcance están desplegadas en staging
  • Los smoke tests pasan
  • Los datos de prueba están configurados
  • La documentación de la API está actualizada
Criterios de salida (el testing termina cuando):
  • Todos los casos de prueba de prioridad alta pasan
  • No hay bugs P1 o P2 abiertos
  • Los tests de performance pasan (carga de página menor a 2 segundos)
  • El suite de regresión pasa

9. Cronograma de testing

| Actividad | Inicio | Fin | Quién |

|-----------|--------|-----|-------|

| Configuración del entorno | Día 1 del sprint | Día 2 del sprint | DevOps |

| Escritura de casos de prueba | Día 1 del sprint | Día 3 del sprint | QA |

| Testing manual | Día 4 del sprint | Día 7 del sprint | QA |

| Scripting de automatización | Día 4 del sprint | Día 8 del sprint | QA Automation |

| Regresión tras corrección de bugs | Día 8 del sprint | Día 9 del sprint | QA |

| Aprobación final | Día 10 del sprint | Día 10 del sprint | QA Lead |

10. Gestión de defectos

¿Cómo se van a rastrear los bugs?

Herramienta: Jira
Proyecto: CHECKOUT
Etiquetas de prioridad: P1 (bloqueador), P2 (mayor), P3 (menor), P4 (cosmético)

P1 bloqueadores: Detener el testing, corregir inmediatamente
P2 mayor: Corregir antes del release
P3 menor: Corregir en el próximo sprint si es posible
P4 cosmético: Agregar al backlog

Plantilla de bug report:
- Entorno
- Pasos para reproducir (numerados)
- Resultado esperado
- Resultado actual
- Captura de pantalla/video
- Navegador/SO

11. Roles y responsabilidades

| Persona | Rol |

|---------|-----|

| Ana García | QA Lead — plan general, aprobación final |

| Carlos López | Ingeniero QA — escritura de casos, testing manual |

| María Torres | QA Automation — scripts de Playwright |

| Diego Ramírez | Desarrollador — corrección de bugs, consultas técnicas |

| Laura Sánchez | Product Manager — requisitos, criterios de aceptación |

Un mini plan completo

Plan de Prueba: Edición de Perfil de Usuario

Versión 1.0 | Autor: Equipo QA | Fecha: 2026-01-15 Funcionalidad: Los usuarios pueden editar su nombre de pantalla y avatar desde su página de perfil.

Alcance

Dentro del alcance: cambio de nombre, carga de avatar (JPEG/PNG, máximo 5MB) y validación de nombre. Fuera del alcance: cambio de email (requiere verificación por email, plan separado) y cambio de contraseña.

Enfoque de testing

Testing funcional manual del camino feliz y casos límite, testing de API del endpoint PUT /api/users/{id} y regresión automatizada para flujos críticos.

Entornos: Staging con cuentas de test pre-configuradas

Datos de prueba necesarios

  • Cuenta de usuario con avatar existente
  • Cuenta de usuario sin avatar
  • Imágenes de prueba: JPEG válido (2MB), PNG válido (4MB), demasiado grande (10MB), formato inválido (PDF)

Riesgos

El límite de tamaño de archivo solo se aplica del lado del cliente (hay que testear también del lado del servidor) y el almacenamiento de avatares en S3 requiere testear qué pasa cuando la carga falla.

Criterios de salida: Todos los bugs P1/P2 cerrados, nombre y avatar se actualizan correctamente para todos los casos de prueba, suite de regresión verde.

Eso es todo. Un buen plan de prueba puede entrar en una página.

Errores comunes

Demasiado vago: "Vamos a testear la funcionalidad de login." ¿Cómo? ¿En todos los navegadores? ¿Todos los roles de usuario? ¿Solo API? ¿Solo UI? Demasiado largo: Un documento de 20 páginas que nadie lee no es útil. Si los stakeholders no lo van a leer, no está comunicando nada. Sin sección de alcance: Sin ítems explícitamente fuera del alcance, cada stakeholder asume que su cosa está cubierta. Sin evaluación de riesgos: Vas a gastar el mismo tiempo en áreas de bajo y alto riesgo en lugar de priorizar. Sin criterios de salida: ¿Cómo sabes cuándo terminaste? "Cuando se nos acaba el tiempo" no es un criterio de salida.

Resumen

Un plan de prueba cubre:

1. Qué se está testeando (y qué no)

2. Cómo se va a testear (manual, automatizado, exploratorio)

3. Dónde ocurre el testing (entornos)

4. Qué datos se necesitan

5. Qué riesgos existen y cómo mitigarlos

6. Cuándo empieza y termina el testing (criterios de entrada/salida)

7. Quién es responsable de qué

→ See also: Testing Basado en Riesgos: Priorizar Qué Testear Cuando No Puedes Testar Todo | Cómo Escribir un Caso de Prueba: Formato, Ejemplos y Errores Comunes | Técnicas de Diseño de Casos de Prueba: EP, BVA, Tablas de Decisión, Transición de Estados