Cuando nadie puede responder si una funcionalidad se probó o no, el problema no es técnico: es de comunicación. Un plan de pruebas formal resuelve ese vacío al dejar por escrito el alcance, la estrategia, los recursos y el calendario de todas las actividades de verificación antes de que comience la ejecución. Funciona como el plano de una casa: sin él, alguien termina poniendo ladrillos en el lugar equivocado.
¿Por qué un plan de pruebas es el plano antes de construir?
El plan de pruebas formal es el documento que describe el alcance, el enfoque, los recursos y el calendario de todas las actividades de prueba [0:38]. A diferencia de decisiones tácticas como elegir qué automatizar, este documento opera a un nivel superior. Su propósito tiene cuatro caras:
- Documenta cómo y cuándo se alcanzarán los objetivos de prueba.
- Confirma que las actividades cumplirán los criterios antes de liberar.
- Funciona como herramienta de comunicación con stakeholders.
- Demuestra que las pruebas siguen la estrategia acordada.
Cuando los stakeholders firman el plan, aceptan qué se prueba, qué no, quién es responsable y qué riesgos necesitan contingencia [1:23]. Es comparable al acuerdo que un inspector de alimentos y el dueño de un restaurante sellan antes de abrir: si algo se omite, ambas partes saben por qué.
¿Cómo definir el alcance y la estrategia de pruebas?
¿Qué entra y qué queda fuera del alcance?
El alcance responde una pregunta directa: ¿qué probamos y qué dejamos fuera? [1:49]. Tiene dos mitades igualmente importantes:
- Lo incluido: ítems de prueba con versiones específicas, funcionalidades desde la perspectiva del usuario y el nivel de riesgo (alto, medio, bajo) calculado con la fórmula de probabilidad por impacto.
- Lo excluido: cada elemento fuera del alcance debe tener una razón explícita [2:22]. Si no aparece en la lista de excluidos, alguien asumirá que se prueba en otro lado y caerá al vacío.
Es como un contrato de envío: dice exactamente qué se despacha y qué no.
¿Cómo conectar riesgo con tipo de prueba?
La estrategia traduce el rating de riesgo en tipos de prueba concretos [2:50]:
- Fallo lógico: prueba funcional.
- Carga pesada: prueba de rendimiento.
- Datos expuestos: prueba de seguridad.
- Cambios frecuentes: prueba de regresión.
También se eligen técnicas de diseño — valores límite, tablas de decisión — según lo que el riesgo demande. Cuando el tiempo aprieta, la pirámide de pruebas prioriza: muchas pruebas pequeñas en la base y pocas de extremo a extremo en la cima [3:12].
¿Cuándo arrancamos y cuándo paramos de probar?
Los criterios de entrada son las condiciones que deben cumplirse antes de iniciar [3:25]. Tres áreas los definen:
- Recursos disponibles: personas, herramientas, ambientes y datos.
- Testware listo: requisitos y casos de prueba documentados.
- Objeto de prueba con calidad mínima, por ejemplo que pase el smoke test.
En marcos ágiles esto se conoce como Definición de Ready.
Los criterios de salida responden la pregunta más difícil: ¿cuándo terminamos? [3:52]. Incluyen medidas numéricas — 95 % de casos pasando, cero defectos críticos abiertos — y condiciones binarias — todas las pruebas ejecutadas, todos los defectos reportados. Quedarse sin tiempo puede ser un criterio de salida válido, siempre que los stakeholders revisen y acepten el riesgo por escrito [4:10]. Decisión consciente, no descuido.
¿Qué más necesita el plan?
El documento también requiere roles con nombre y apellido, dependencias vinculadas a fechas de desarrollo — no a fechas fijas del calendario — y una sección de riesgos donde cada riesgo tiene su contingencia documentada [4:22].
Un ejemplo rápido para una pasarela de pagos:
- Alcance incluido: transacciones con tarjeta y descuentos.
- Alcance excluido: reembolsos, porque no son parte del release.
- Estrategia: caja negra con particiones de equivalencia para flujos principales e integración con el proveedor externo.
- Entrada: build pasa smoke test, ambiente con datos de prueba configurados.
- Salida: 100 % de casos de riesgo alto ejecutados, cero críticos abiertos.
- Riesgo: entrega tardía del API; contingencia: desplazar cronograma.
Cada sección responde una sola pregunta y se detiene ahí. Viñetas de tres a diez palabras bastan [4:55].
La prueba definitiva para cualquier plan es simple: ¿puede alguien leerlo y decir qué no se va a probar sin preguntarte nada? [5:10]. Si las exclusiones son explícitas, cada una tiene razón documentada y los criterios de salida no mencionan funcionalidades excluidas, el plan se sostiene solo. Piensa en la próxima funcionalidad que vayas a liberar y pregúntate si podrías escribir ese contrato en una sola página. Si te animas, comparte tu experiencia armando planes de pruebas y qué sección te resulta más difícil de definir.
