Un plan de pruebas es un documento corto que responde cinco preguntas antes de que empieces a probar: qué vas a probar, qué vas a dejar fuera a propósito, cómo lo vas a probar, cuándo consideras que terminaste y qué riesgo estás dispuesto a aceptar. Esa es la definición completa. Todo lo demás que te hayan mostrado con el nombre de "plan de pruebas" (esas plantillas de doscientas páginas con veinte secciones que nadie abre) es relleno que estorba.
La confusión viene de creer que el plan es un trámite que hay que entregar para que un jefe lo firme. No lo es. El plan es la respuesta escrita a una decisión que igual vas a tomar, quieras o no: dónde poner el esfuerzo limitado que tienes. Si no la escribes, la tomas de todos modos, pero a ciegas y sin que nadie pueda cuestionarla.
Si no puedes escribir en una página qué no vas a probar, es que todavía no decidiste qué sí.
01 · el propósitoPara qué sirve de verdad un plan de pruebas
El estándar ISO/IEC/IEEE 29119, que es la referencia internacional de procesos de prueba, define el plan como el documento que describe el alcance, el enfoque, los recursos y el cronograma de las actividades de prueba. Suena a burocracia, pero cada palabra ahí carga un compromiso real. El alcance es una frontera: dice qué entra y qué queda fuera. El enfoque es una apuesta: dice con qué técnicas vas a atacar. Los recursos son un límite: dicen cuánto tiempo y cuántas manos tienes. El cronograma es una promesa: dice cuándo.
El valor del plan no está en el papel, está en las conversaciones que te obliga a tener antes de empezar. Cuando escribes "no vamos a probar el flujo de pagos con tarjetas internacionales en esta entrega", alguien puede levantar la mano y decir que eso es justo lo que más importa. Esa objeción vale oro, y solo aparece si escribiste la frontera. Un plan que no provoca ninguna discusión probablemente no dijo nada arriesgado, y por lo tanto no dijo nada útil.
Se confunden todo el tiempo. El plan de pruebas decide la estrategia: qué áreas, con qué prioridad, hasta dónde. Los casos de prueba son el detalle táctico: las entradas y los resultados esperados concretos. El plan es el mapa; los casos son los pasos. Escribir doscientos casos sin un plan es caminar rápido sin saber hacia dónde.
02 · las piezasQué contiene un plan que sí se lee
Un plan útil cabe en una página y tiene pocas partes, pero ninguna es opcional. La primera es el alcance: una lista corta de qué se prueba y, con la misma importancia, qué no. Lo segundo casi siempre se omite y es lo más valioso, porque hace explícito el riesgo que estás aceptando a sabiendas.
La segunda pieza es el enfoque: qué niveles y tipos de prueba vas a usar y en qué proporción. Aquí decides si esto se automatiza o se explora a mano, si pesa más lo funcional o lo no funcional, dónde va el músculo. La tercera pieza son los criterios: el de entrada, que dice cuándo el sistema está listo para empezar a probarse, y el de salida, que dice cuándo puedes parar con la conciencia tranquila.
Los criterios de salida son la parte que más gente se salta, y por eso tantos equipos prueban hasta que se acaba el tiempo en vez de hasta que se cumple una condición. "Paramos cuando pasen todas las pruebas críticas y no queden defectos bloqueantes abiertos" es un criterio. "Paramos el viernes" es una rendición.
03 · el riesgoCómo el riesgo decide dónde probar
La pregunta que ordena todo un plan es una sola: si esto falla, ¿cuánto duele? Probarlo todo con la misma intensidad es imposible, porque el número de estados y caminos de cualquier sistema real es enorme. El testing exhaustivo es un mito, y un plan honesto arranca aceptándolo. Lo que hace un buen plan es repartir el esfuerzo según el riesgo, no según lo que sea cómodo de probar.
El riesgo tiene dos dimensiones que conviene separar: qué tan probable es que algo falle y qué tan grave sería si falla. Un error tipográfico en un pie de página es probable pero inofensivo. Un error en el cálculo de un cobro es menos frecuente pero catastrófico. El plan pone el músculo donde la probabilidad y el impacto se multiplican alto, y deja explícito, por escrito, lo que decide no cubrir. Esa priorización basada en riesgo es lo que separa un plan profesional de una lista de deseos.
Aquí es donde el plan deja de ser papeleo y se vuelve una herramienta de negociación. Cuando un plan dice "con el tiempo disponible cubrimos a fondo pagos y registro, y solo hacemos chequeo de humo del panel de reportes", le está dando a quien decide una elección clara: o acepta ese riesgo, o suelta más tiempo. Sin plan, esa decisión se toma igual, pero por accidente y sin que nadie la firme.
04 · la prácticaCómo escribir uno sin morir en el intento
Empieza por el alcance en dos columnas: "sí probamos" y "no probamos". Llena primero la de la derecha, la de lo que dejas fuera, porque es la que de verdad define tu apuesta. Sigue con tres o cuatro riesgos ordenados por gravedad, y para cada uno una línea de cómo lo vas a atacar. Cierra con un criterio de salida medible y con quién hace qué. Si eso te ocupó más de una página, sobra texto.
Un plan es un documento vivo, no una lápida. El propio ISTQB describe la planificación como una actividad continua: a medida que aparecen defectos, cambian prioridades o se mueve una fecha, el plan se actualiza. Un plan que quedó congelado el primer día y nadie volvió a mirar dejó de ser un plan y se convirtió en decoración. La utilidad está en revisarlo cuando la realidad contradice lo que supusiste.
Y no lo escribas para archivarlo: escríbelo para provocar la conversación correcta antes de que sea cara. El mejor plan de pruebas no es el más completo ni el más largo. Es el que hace que las decisiones difíciles (qué sacrificamos, cuánto riesgo aceptamos, cuándo paramos) se tomen a la luz, por escrito y a tiempo, en vez de descubrirse el día del incidente en producción.
Fuentes
- ISO/IEC/IEEE 29119-3:2021. Software and systems engineering. Software testing. Part 3: Test documentation. International Organization for Standardization. Define la estructura y el contenido del plan de pruebas y demás documentación de prueba. iso.org/standard/79429.html.
- International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus, v4.0 (2023). Planificación de prueba como actividad continua, criterios de entrada y salida, y priorización basada en riesgo. istqb.org.
- ISO/IEC 25010:2023. Systems and software engineering. SQuaRE. Product quality model. International Organization for Standardization. Marco de características de calidad que orienta qué cualidades cubrir en el enfoque del plan. iso.org/standard/78176.html.
- Myers, G. J., Sandler, C. & Badgett, T. (2011). The Art of Software Testing, 3.ª ed. John Wiley & Sons. Tratamiento clásico de la planificación y del testing exhaustivo como imposible en la práctica.