Qué incluye
Fíjate en que las barras de ejecución se solapan y en que el ciclo de incidencias corre a lo largo de todas ellas. Así es como se ve un cronograma de pruebas real:
- Planificación de pruebas y criterios — Estrategia de pruebas, alcance y priorización por riesgo, los criterios de entrada y de salida de cada fase escritos antes de que empiece la ejecución, estimación y plan de recursos. Hito: plan de pruebas y criterios aprobados.
- Preparación de entorno y datos de prueba — La puerta de verdad. Construcción y configuración del entorno, simuladores de integración, aprovisionamiento y anonimización de datos de prueba, accesos y cuentas, y una prueba de humo que valide el entorno antes de que nadie pruebe en él. Hito: criterios de entrada del entorno cumplidos.
- Diseño de pruebas y automatización — Diseño de condiciones y casos de prueba, trazabilidad hacia los requisitos, el marco de automatización, construcción de la suite de regresión y los scripts de pruebas de rendimiento. Hito: casos listos para ejecución.
- Ejecución: unitarias, integración, sistema — Oleadas de ejecución solapadas en lugar de una cola: pruebas unitarias y de componente, pruebas de integración y de interfaces, y después pruebas de sistema y de seguridad. Hito: criterios de salida de pruebas de sistema cumplidos.
- Ciclo de triaje, corrección y reprueba — El bucle que de verdad consume el calendario: triaje diario, asignación de severidad, ciclos de corrección, reprueba e impacto en regresión, y las decisiones sobre incidencias diferidas. Hito: umbrales de incidencias alcanzados.
- UAT, regresión y preparación para la entrega — Pruebas de aceptación por usuarios de negocio, regresión completa, ejecuciones de rendimiento y carga, la revisión de preparación para la entrega y la aprobación. Hito: entrega aprobada.
Cómo personalizarla
- Escribe criterios de entrada y de salida reales en las notas de cada fila de fase (tasa de éxito, incidencias abiertas por severidad, cobertura) para que las puertas sean comprobables y no retóricas.
- Solapa las oleadas de ejecución según tu cadencia de compilación; encolarlas de punta a punta casi siempre exagera la duración total e infravalora el riesgo.
- Dimensiona el ciclo de incidencias con tus tasas históricas de descubrimiento y de corrección, no con un porcentaje del esfuerzo de pruebas.
- Añade una fila por interfaz o sistema integrado si las pruebas de integración dependen de terceros que controlan sus propios entornos.
- Adelanta la UAT por módulo si entregas de forma incremental en lugar de en una sola entrega.
- Si los datos de prueba proceden de producción, añade una barra propia para la anonimización y para su validación: usar datos personales reales en un entorno de pruebas es un tratamiento que necesita base jurídica, y no es una tarea que se resuelva la semana anterior.
- Añade una fila de congelación de código antes de la regresión, y mantén la regresión detrás: la regresión contra una compilación en movimiento no es regresión.
Consejos de programación
- Haz numéricos los criterios de salida. «Pruebas terminadas» no es una puerta; «cero incidencias abiertas de severidad 1, menos de cinco de severidad 2, 95% de los casos previstos ejecutados» sí lo es.
- Aprovisiona los datos antes de que termine el diseño de pruebas. Los diseñadores descubren huecos de datos, y el aprovisionamiento de datos tiene el plazo más largo de todo el plan.
- Haz triaje diario durante el pico de ejecución. Una reunión de triaje semanal significa que una incidencia puede estar cinco días parada antes de que alguien decida quién la corrige.
- Protege la regresión del flujo de correcciones. Cada corrección tardía invalida parte de la ejecución de regresión, y para eso existe la fila de congelación de código.
- Sigue la tasa de descubrimiento de incidencias, no el recuento. Una tasa de descubrimiento que cae es la señal honesta de que una fase está convergiendo; un recuento bruto no dice casi nada.
Plantillas relacionadas
- Plantilla de diagrama de Gantt para desarrollo de software
- Plantilla de planificación de sprint
- Plantilla de plan de lanzamiento de una app móvil
- Plantilla de plan de rediseño de un sitio web
- Plantilla de plan de proyecto de migración de datos
- Ver todas las plantillas de diagramas de Gantt
Esta plantilla está en español. Las páginas relacionadas que aún no se han traducido se abren en inglés.
Preguntas frecuentes
¿Qué son los criterios de entrada y de salida en un plan de pruebas?
Los criterios de entrada son las condiciones que deben cumplirse antes de que una fase pueda empezar: entorno estable, compilación desplegada, datos cargados, prueba de humo superada. Los de salida son las condiciones que deben cumplirse antes de darla por terminada: cobertura de ejecución, tasa de éxito y número de incidencias abiertas por severidad. Ambos deberían ser numéricos, acordados antes de la ejecución y hacerse cumplir.
¿Por qué se solapan las fases de prueba en lugar de ir en serie?
Porque las compilaciones llegan de forma incremental. Las pruebas de integración pueden empezar sobre los módulos que ya pasaron las unitarias, y la UAT puede arrancar sobre los recorridos terminados mientras las pruebas de sistema siguen en otro sitio. Encolar las fases infla el cronograma y esconde la restricción real, que suele ser el ciclo de corrección y reprueba.
¿Cuánto tiempo hay que reservar para corregir incidencias?
Dimensiónalo con tu propia historia: incidencias encontradas por día de prueba, proporción que requiere corrección, y tu plazo medio de corrección más reprueba. En la mayoría de los proyectos ese bucle es la barra más larga del diagrama. Asignar un porcentaje plano del esfuerzo de pruebas es la forma habitual de que un calendario se desvíe.
¿Qué hacemos si el entorno de pruebas no está listo?
No empieces la ejecución. Probar contra un entorno inestable produce incidencias de entorno y no de producto, y ese tiempo no se recupera. La plantilla convierte la preparación del entorno en un hito con puerta y una prueba de humo delante precisamente para que esa decisión sea visible en lugar de absorberse en silencio.
¿Cuándo debe empezar la UAT?
Cuando se cumplan los criterios de salida de pruebas de sistema para el alcance que va a cubrir la UAT, no cuando haya terminado todo el sistema en todas partes. La UAT es validación de negocio, así que necesita una compilación estable y datos con forma real; ejecutarla contra una compilación que sigue recibiendo correcciones desperdicia a los usuarios de negocio, que son el recurso más escaso del plan.
¿Se pueden usar datos de producción para probar?
No sin más. Si contienen datos personales, copiarlos a un entorno de pruebas es un tratamiento con sus propias exigencias: base jurídica, minimización, anonimización o seudonimización efectiva y control de accesos. Lo práctico es programar la anonimización como una barra con su propia validación, porque es lento y porque descubrirlo tarde bloquea toda la fase de ejecución.
¿Es gratuita?
Sí, con descarga en Excel, PowerPoint y CSV y edición online sin registro ni marca de agua.