Glosario · Fundamentos de testing
Plan de pruebas
En inglés: Test plan
También llamado: planes de pruebas, plan de test, planificación de pruebas, test planning
Definición
Documento que define alcance, enfoque, recursos, calendario, entornos, riesgos y criterios de entrada y salida de las pruebas de una release o un proyecto.
Un plan de pruebas (test plan) describe cómo se van a realizar las pruebas de una release, un proyecto o una funcionalidad concretos: qué está dentro y fuera del alcance, qué tipos de pruebas se aplican, quién hace qué, dónde se ejecuta, cuándo ocurre y cómo sabrá el equipo que ha terminado. Es el acuerdo sobre las pruebas entre QA, desarrollo y producto, puesto por escrito antes de empezar la ejecución. El estándar IEEE 829 (hoy sustituido por ISO/IEC/IEEE 29119-3) es la plantilla clásica.
Qué contiene un plan de pruebas útil
- Alcance: las funcionalidades incluidas y, igual de importante, las que quedan explícitamente fuera.
- Enfoque: niveles y tipos de prueba (unitarias, API, UI, rendimiento, seguridad, accesibilidad) y qué se automatiza frente a qué se hace manualmente.
- Entornos y datos: qué entornos, cómo se crean o enmascaran los datos de prueba, sandboxes de terceros.
- Criterios de entrada: lo que debe cumplirse antes de empezar a probar, como “build desplegado en staging y smoke tests en verde”.
- Criterios de salida: qué significa “terminado”, como “ningún defecto crítico o grave abierto, todos los escenarios P1 superados, suite de regresión en verde”.
- Riesgos y mitigaciones: por ejemplo, “el sandbox de pagos es inestable, así que lo sustituiremos por un stub en los tests funcionales y ejecutaremos una comprobación end-to-end diaria contra el sandbox real”.
- Roles, calendario y entregables: quién prueba qué, las fechas clave y qué informes se generan.
Plan de pruebas frente a estrategia de pruebas
Una estrategia de pruebas es el enfoque de alto nivel y más duradero para un producto u organización: los principios, niveles, herramientas y estándares de prueba. Un plan de pruebas aplica esa estrategia a una release o proyecto con un alcance, fechas y personas concretos. Muchos equipos ágiles mantienen una página de estrategia ligera y un plan breve por release o épica.
Errores comunes
- Escribir un documento de 40 páginas que nadie lee. En los equipos ágiles, un plan de una página que se mantiene al día es mejor que uno exhaustivo que queda desfasado en el segundo sprint.
- Criterios de salida vagos. “Pruebas completadas” no es medible. Indica las condiciones.
- Sin sección de fuera de alcance. Las exclusiones no declaradas se convierten en discusiones después de la release.