- Un plan de pruebas es el documento que describe los objetivos, los recursos y los procesos de un proyecto de prueba: qué se va a probar, cómo, con quién, cuándo y cómo sabremos que terminamos.
- Según ISTQB Foundation Level 4.0 incluye: contexto (alcance, objetivos, base de prueba), supuestos y restricciones, implicados, comunicación, registro de riesgos, enfoque de prueba, presupuesto y calendario.
- El enfoque de prueba es el corazón del plan: niveles, tipos y técnicas, entregables, criterios de entrada y salida, independencia, métricas, datos y entorno de prueba.
- Los criterios de salida definen cuándo se puede dar por terminada la prueba (cobertura, defectos abiertos, pruebas ejecutadas). En ágil equivalen a la Definición de Hecho.
- Estima con técnicas reconocidas: proporciones, extrapolación, Delphi de banda ancha (planning poker) o tres puntos: E = (a + 4m + b) / 6.
- Un plan no es un trámite: es un documento vivo que se actualiza y debe aceptarse por todos los implicados. Abajo tienes un ejemplo completo y una plantilla en Word gratuita.
Muchos equipos ven el plan de pruebas como un documento que se llena una vez para cumplir y nadie vuelve a leer. Pero cuando el proyecto se complica (llega tarde el entorno, cambia el alcance, aparece un defecto crítico a dos días de salir) el plan es lo que te permite tomar decisiones con calma y explicarlas.
En esta guía verás qué incluye un plan de pruebas según el programa ISTQB Foundation Level 4.0 (capítulo 5) y el programa ISTQB Advanced Level Test Management v3.0, con un ejemplo real resuelto y una plantilla descargable.
¿Qué es un plan de pruebas de software?
Un plan de pruebas describe los objetivos, los recursos y los procesos de un proyecto de prueba. Según ISTQB, un plan de pruebas:
- Documenta los medios y el calendario para alcanzar los objetivos de prueba.
- Ayuda a asegurar que las actividades de prueba cumplirán los criterios establecidos.
- Sirve como medio de comunicación con el equipo y los demás implicados.
- Demuestra que la prueba se ajustará a la política y la estrategia de prueba existentes (o explica por qué se desviará).
El syllabus agrega una idea valiosa: el proceso de elaborar el plan obliga a pensar en los retos futuros (riesgos, calendarios, personas, herramientas, costos, esfuerzo). A veces el mayor valor no está en el documento, sino en las conversaciones que provoca.
Plan de pruebas, estrategia de prueba y política de prueba
| Documento | Alcance | Qué responde |
|---|---|---|
| Política de prueba | Organización | ¿Por qué probamos y qué entendemos por calidad? |
| Estrategia de prueba organizacional | Organización | ¿Cómo probamos en general en esta empresa? |
| Estrategia de prueba del proyecto | Proyecto, entrega o producto | ¿Qué enfoque usaremos en este contexto concreto? Suele documentarse dentro del plan. |
| Plan de pruebas | Proyecto, nivel, tipo o iteración | ¿Qué, cómo, quién, cuándo, con qué recursos y cuándo terminamos? |
Tipos de plan de pruebas
El programa Test Management describe que el plan puede definirse a distintos niveles:
- Plan maestro (o de proyecto): cubre todo el proyecto o la entrega.
- Plan de nivel: uno por nivel de prueba, por ejemplo de sistema o de aceptación.
- Plan por característica de calidad: por ejemplo, un plan de pruebas de seguridad o de rendimiento.
- Plan de iteración: en desarrollo ágil o híbrido, acordado para cada sprint o iteración.
¿Qué incluye un plan de pruebas? Contenido según ISTQB
Este es el contenido habitual que enumera el syllabus CTFL 4.0 (sección 5.1.1), con lo que conviene escribir en cada parte:
| Sección | Qué incluye | Pregunta que responde |
|---|---|---|
| 1. Contexto de la prueba | Alcance, objetivos de prueba, restricciones, base de prueba | ¿Qué probamos y para qué? |
| 2. Supuestos y restricciones | Lo que damos por hecho y lo que nos limita | ¿Qué podría invalidar este plan? |
| 3. Implicados | Roles, responsabilidades, relevancia para la prueba, necesidades de contratación y formación | ¿Quién hace qué? |
| 4. Comunicación | Formas y frecuencia de comunicación, plantillas de documentación | ¿Cómo y cada cuánto informamos? |
| 5. Registro de riesgos | Riesgos de producto y de proyecto con probabilidad, impacto y mitigación | ¿Qué puede salir mal? |
| 6. Enfoque de prueba | Niveles, tipos y técnicas; entregables; criterios de entrada y salida; independencia; métricas; datos y entorno de prueba; desviaciones de la estrategia | ¿Cómo vamos a probar? |
| 7. Presupuesto y calendario | Costos, hitos y fechas | ¿Cuánto cuesta y cuándo? |
Para más detalle, el syllabus remite a la norma ISO/IEC/IEEE 29119-3, que incluye plantillas de documentación de prueba.
Ejemplo de plan de pruebas: checkout de una tienda en línea
Veamos un ejemplo resumido para una entrega real: una tienda en línea que lanza un nuevo proceso de pago (checkout) con pago en mensualidades.
1. Contexto
- Dentro del alcance: carrito, cálculo de envío, cupones, pago con tarjeta y en mensualidades, confirmación por correo, web y app Android/iOS.
- Fuera del alcance: devoluciones y facturación (se entregan en la siguiente versión).
- Base de prueba: historias de usuario HU-30 a HU-52 con criterios de aceptación, contrato de API de la pasarela de pagos, diseño en Figma.
2. Objetivos de prueba (S.M.A.R.T.)
El programa Test Management recomienda redactar los objetivos y criterios de salida como metas específicas, medibles, alcanzables, relevantes y con plazo:
- Cubrir el 100% de los criterios de aceptación de HU-30 a HU-52 antes del congelamiento del código.
- Confirmar que el checkout responde en 2 segundos o menos para el 95% de las operaciones con la carga esperada en temporada alta (Black Friday o Buen Fin).
- Automatizar la regresión del flujo de compra principal en el pipeline de CI antes de la salida.
3. Supuestos y restricciones
- Supuesto: la pasarela de pagos ofrece un entorno sandbox estable desde la semana 2.
- Restricción: fecha de salida fija por campaña comercial; dos testers disponibles.
4. Implicados y comunicación
- QA Lead (planificación, control, informes), 2 testers (diseño y ejecución), desarrolladores (pruebas de componente), Product Owner (criterios de aceptación y UAT), DevOps (entornos).
- Informe de avance semanal al gerente de proyecto; defectos críticos comunicados de inmediato por chat y en la herramienta de defectos.
5. Registro de riesgos
| Riesgo | Tipo | Prob. | Impacto | Nivel | Mitigación |
|---|---|---|---|---|---|
| Cálculo erróneo de mensualidades e intereses | Producto | 3 | 5 | 15 | Tabla de decisión y valores frontera; revisión de reglas con Finanzas |
| Lentitud en hora pico | Producto | 3 | 4 | 12 | Prueba de rendimiento con carga esperada y pico |
| Cobro duplicado si se cae la red | Producto | 2 | 5 | 10 | Pruebas de fiabilidad y de recuperación |
| Sandbox de la pasarela no disponible a tiempo | Proyecto | 4 | 4 | 16 | Virtualización del servicio; fecha comprometida con el proveedor |
6. Enfoque de prueba
- Niveles: componente e integración de componentes (desarrollo), sistema e integración de sistemas (QA), aceptación (negocio).
- Tipos: funcional, no funcional (rendimiento, seguridad, usabilidad), confirmación y regresión.
- Técnicas: partición de equivalencia y valores frontera para montos y cupones; tabla de decisión para reglas de envío; transición de estados para el ciclo de vida del pedido; prueba exploratoria por sesiones.
- Criterios de entrada: entorno de QA verificado, historias con criterios de aceptación comprobables, pruebas de humo pasadas.
- Criterios de salida: 100% de casos de prioridad alta ejecutados, 0 defectos críticos abiertos, regresión automatizada en verde, riesgo residual aceptado por el Product Owner.
- Métricas: avance de ejecución, tasa de éxito, defectos por severidad, cobertura de criterios de aceptación, riesgo residual.
Si necesitas repasar la diferencia entre niveles y tipos de prueba antes de definir tu enfoque, revisa la guía de tipos de pruebas de software según ISTQB.
7. Presupuesto y calendario
Seis semanas: planificación y diseño (semanas 1 y 2), ciclos de ejecución (3 y 4), rendimiento y regresión (5), UAT y compleción (6). El esfuerzo se estima con la técnica de tres puntos (ver abajo).
Los casos de prueba que salen de este enfoque los puedes documentar con nuestra guía y plantilla de casos de prueba con ejemplos.
Criterios de entrada y criterios de salida
Son de las partes más preguntadas del plan, tanto en entrevistas como en el examen.
| Criterios de entrada | Criterios de salida | |
|---|---|---|
| Qué definen | Las precondiciones para empezar una actividad | Lo que debe lograrse para declararla completada |
| Ejemplos típicos (ISTQB) | Disponibilidad de recursos (personas, herramientas, entornos, datos, presupuesto, tiempo); disponibilidad del material de prueba (base de prueba, requisitos comprobables, casos); nivel de calidad inicial (pruebas de humo pasadas) | Medidas de completitud (cobertura alcanzada, defectos sin resolver, densidad de defectos, casos fallidos) y criterios de compleción (pruebas planificadas ejecutadas, prueba estática realizada, defectos notificados, regresión automatizada) |
| En ágil | Definición de Preparado (Definition of Ready) | Definición de Hecho (Definition of Done) |
Un detalle que muchos desconocen: según ISTQB, quedarse sin tiempo o sin presupuesto también puede ser un criterio de salida válido, siempre que los implicados hayan revisado y aceptado el riesgo de salir a producción sin más pruebas. Por eso el plan debe dejar claro quién acepta ese riesgo.
Estimación del esfuerzo de prueba
La estimación siempre se basa en supuestos y está sujeta a error. Por eso conviene descomponer las tareas grandes en tareas pequeñas (que se estiman con más precisión) y documentar los supuestos. ISTQB Foundation describe cuatro técnicas:
| Técnica | Tipo | Cómo funciona | Ejemplo |
|---|---|---|---|
| Basada en proporciones | Métricas | Usa proporciones históricas de proyectos similares de la organización. | Si la relación desarrollo:prueba fue 3:2 y el desarrollo se estima en 600 días-persona, la prueba se estima en 400. |
| Extrapolación | Métricas | Mide temprano en el proyecto actual y proyecta el resto. | Esfuerzo de la próxima iteración = promedio de las tres anteriores. |
| Delphi de banda ancha | Expertos | Cada experto estima por separado; se discuten las diferencias y se repite hasta el consenso. El planning poker es una variante. | El equipo vota con cartas los puntos de una historia. |
| Tres puntos | Expertos | E = (a + 4m + b) / 6 y desviación estándar = (b − a) / 6. | Ver ejemplo abajo. |
Ejemplo resuelto de estimación de tres puntos
Para la ejecución de pruebas del checkout, el equipo estima: optimista a = 40 h, más probable m = 56 h, pesimista b = 90 h.
- E = (40 + 4 × 56 + 90) / 6 = 354 / 6 = 59 horas
- Desviación estándar = (90 − 40) / 6 ≈ 8.3 horas
- Resultado para comunicar: entre 51 y 67 horas aproximadamente.
El programa Test Management agrega los factores que influyen en el esfuerzo: el producto (calidad de la base de prueba, tamaño, complejidad, requisitos de calidad como seguridad), el proceso de desarrollo (madurez, modelo de ciclo de vida, herramientas y automatización disponibles), las personas (habilidades, experiencia, vacaciones), los resultados de prueba (cantidad y severidad de defectos, retrabajo) y el contexto (equipos distribuidos, trabajo remoto o presencial).
Riesgos en el plan de pruebas
ISTQB distingue dos tipos de riesgo:
- Riesgos de proyecto: relacionados con la gestión y el control: retrasos, estimaciones inexactas, falta de personal o de competencias, problemas técnicos o con proveedores.
- Riesgos de producto: relacionados con las características de calidad del producto: funcionalidad incorrecta, cálculos erróneos, tiempos de respuesta inadecuados, mala experiencia de usuario, vulnerabilidades.
El nivel de riesgo combina probabilidad e impacto: de forma cuantitativa (multiplicándolos) o cualitativa con una matriz de riesgo. Ese nivel decide cuánta prueba merece cada área: los riesgos altos se prueban antes, con técnicas más rigurosas y por las personas más calificadas.
El programa Test Management describe dos formas de priorizar la ejecución por riesgo: en profundidad (de mayor a menor nivel de riesgo, para mitigar primero lo más grave) y en amplitud (al menos una prueba por cada riesgo primero, para tener pronto una visión general). En la práctica se suele empezar en profundidad y cambiar a amplitud cuando el tiempo se agota.
El plan de pruebas en equipos ágiles
En ágil no desaparece la planificación; cambia de forma. ISTQB describe dos tipos:
- Planificación de la entrega (release): los testers participan en escribir historias y criterios de aceptación comprobables, en el análisis de riesgos, en estimar el esfuerzo de prueba y en definir el enfoque de prueba de todas las iteraciones.
- Planificación de la iteración: los testers analizan el riesgo de cada historia, evalúan si se puede probar, la dividen en tareas (incluidas las de prueba) y estiman cada tarea.
Un plan maestro ligero (una o dos páginas) más la Definición de Preparado y la Definición de Hecho suele ser suficiente en equipos ágiles maduros. Si trabajas en este contexto, te interesa la certificación ISTQB Agile Tester y el curso de ISTQB Agile Tester.
Monitorización, control e informes
El plan no termina al aprobarse. Durante el proyecto, la monitorización compara el avance real con el plan y el control toma acciones correctivas: volver a priorizar cuando un riesgo se materializa, ajustar el calendario si el entorno llega tarde o agregar recursos.
Los informes de avance suelen incluir el periodo, el avance contra lo planeado, los obstáculos y sus soluciones, las métricas, los riesgos nuevos o modificados y lo planeado para el siguiente periodo. Al cerrar, el informe de compleción resume la prueba, evalúa la calidad contra los criterios de salida, explica desviaciones, lista riesgos no mitigados y defectos sin resolver, y documenta lecciones aprendidas.
Estos temas (plan, estimación, riesgos, métricas e informes) forman el capítulo 5 del examen Foundation Level y suelen incluir preguntas de cálculo. Pon a prueba lo que sabes con el simulador gratuito del examen ISTQB Foundation.
Errores comunes al hacer un plan de pruebas
- Copiar un plan de otro proyecto sin adaptarlo: la prueba depende del contexto.
- No escribir lo que queda fuera del alcance, lo que provoca malentendidos al final.
- Criterios de salida vagos como "cuando esté estable". Hazlos medibles.
- Ignorar los riesgos de proyecto: un entorno que llega tarde arruina cualquier calendario.
- No conseguir la aceptación de los implicados. El programa Test Management es claro: el plan debe ser aceptado por todos y los desacuerdos deben resolverse.
- Tratarlo como documento estático. La planificación es iterativa y el plan se actualiza conforme avanza el proyecto.
Plantilla de plan de pruebas en Word
Preparamos una plantilla editable con todas las secciones de esta guía, textos de ayuda en gris para saber qué escribir en cada parte y ejemplos ya llenos que puedes adaptar:
- Control del documento e historial de versiones
- Contexto: alcance, fuera del alcance, objetivos S.M.A.R.T. y base de prueba
- Supuestos, restricciones, implicados y plan de comunicación
- Registro de riesgos de producto y de proyecto con nivel de riesgo
- Enfoque de prueba: niveles, tipos, técnicas, automatización, criterios de entrada y salida, métricas, datos y entorno
- Estimación de tres puntos, calendario, gestión de defectos y aprobaciones
Si vas por el camino de la gestión, también te pueden interesar las certificaciones ISTQB Expert Level Test Management, TMMi (mejora de procesos de prueba) y Agile Test Leadership at Scale.
Preguntas frecuentes
¿Qué es un plan de pruebas de software?
Es el documento que describe los objetivos, los recursos y los procesos de un proyecto de prueba: qué se probará, cómo, quién lo hará, cuándo, con qué recursos y con qué criterios se dará por terminada la prueba.
¿Qué debe incluir un plan de pruebas?
Según ISTQB Foundation Level 4.0: contexto de la prueba (alcance, objetivos, restricciones, base de prueba), supuestos y restricciones, implicados, comunicación, registro de riesgos, enfoque de prueba (niveles, tipos, técnicas, entregables, criterios de entrada y salida, métricas, datos y entorno) y presupuesto y calendario.
¿Quién elabora el plan de pruebas?
Normalmente quien asume el rol de gestión de la prueba (test manager, QA lead o líder de equipo), con la participación de testers, desarrolladores, Product Owner y demás implicados, que deben aceptarlo.
¿Cuál es la diferencia entre plan de pruebas y estrategia de prueba?
La estrategia describe el enfoque de prueba, ya sea para toda la organización o para un proyecto concreto. El plan aterriza ese enfoque en un proyecto, nivel o iteración específicos, con alcance, recursos, calendario, riesgos y criterios de salida. La estrategia del proyecto suele documentarse dentro del plan.
¿Qué son los criterios de entrada y salida en un plan de pruebas?
Los criterios de entrada son las precondiciones para iniciar una actividad de prueba, como tener el entorno listo o que pasen las pruebas de humo. Los criterios de salida definen cuándo se puede declarar terminada, por ejemplo, la cobertura alcanzada o cero defectos críticos abiertos.
¿Se hace plan de pruebas en metodologías ágiles?
Sí, aunque más ligero. En ágil se planifica a nivel de entrega y de iteración, y los criterios de entrada y salida se expresan como Definición de Preparado y Definición de Hecho.
¿Dónde descargo una plantilla de plan de pruebas?
En esta guía puedes descargar gratis la plantilla de plan de pruebas de Cool Testers en Word, con todas las secciones recomendadas por ISTQB, textos de ayuda y ejemplos llenos.