Probar sin un plan de pruebas es como viajar sin mapa: puede que llegues, pero seguro das vueltas de más y te pierdes lo importante por el camino. Un buen plan pone a todo el equipo de acuerdo sobre qué se va a probar, cómo, cuándo y con qué criterio se considerará que algo está listo. Y no tiene por qué ser un documento de cuarenta páginas que nadie lee.
Qué es y para qué sirve
Es el documento que define el alcance, el enfoque, los recursos y el calendario de las pruebas de un proyecto o de un release. Responde a preguntas muy concretas: qué funcionalidades se prueban y cuáles quedan fuera, quién lo hará, con qué herramientas, en qué entornos y cómo se decidirá si se puede liberar. Su gran utilidad práctica es que obliga a tomar esas decisiones antes de empezar, cuando todavía hay margen, y no a mitad de camino, cuando hay prisa.
Conviene distinguirlo de la estrategia de testing. La estrategia es el marco general de la organización; el plan es su aplicación a un proyecto concreto.
Qué debería llevar un plan de pruebas
Un plan útil empieza por el objetivo y el alcance, incluyendo lo que queda fuera con su justificación, porque lo no probado también es una decisión y es mejor que sea consciente. Sigue con el enfoque: qué tipos de prueba se harán (funcionales, de regresión, de API, de rendimiento) y qué se automatiza. Define los criterios de entrada, es decir, las condiciones para empezar a probar, como un build estable y un entorno disponible, y los de salida, las condiciones para darlas por terminadas, como los casos críticos ejecutados y ningún defecto bloqueante abierto.
Después vienen los entornos y los datos de prueba, los roles y responsabilidades (quién diseña, ejecuta, revisa y aprueba), el calendario con sus hitos, los riesgos con un plan de contingencia y los entregables: casos de prueba, informes de ejecución y resumen de defectos. No hace falta que cada punto ocupe una página; a veces una frase basta.
Cómo escribirlo sin sufrir
El mejor orden es entender primero el contexto: leer los requisitos, hablar con producto y con desarrollo y ver qué ha cambiado desde el último release. A partir de ahí, identifica los riesgos, porque son los que deciden dónde poner el esfuerzo. Define el alcance, elige el enfoque y estima el esfuerzo y los recursos a partir de la experiencia en proyectos anteriores. Acuerda los criterios de entrada y de salida con el resto del equipo y, antes de empezar, compártelo con desarrollo y producto para validarlo; un plan que solo conoce QA pierde la mitad de su valor.
Que se quede vivo
Lo que convierte un plan en una herramienta de trabajo es que sea breve, que se actualice cuando cambie el alcance o aparezcan riesgos y que esté en un lugar al que todo el equipo tenga acceso. Una o dos páginas bien pensadas superan a un documento enorme. Y evita los fallos de siempre: copiar plantillas sin adaptarlas, no definir criterios de salida (lo que garantiza discusiones el día de liberar), olvidar los riesgos o dejar el calendario sin margen.
Para mí, un plan de pruebas vale la pena cuando cambia decisiones: priorizar, decir que no a algo, avisar a tiempo de un riesgo. Si solo se redacta para cumplir con un requisito, es tiempo perdido.
Si quieres que tu equipo aprenda a planificar pruebas con método, pide información en el formulario de contacto y te contamos nuestras capacitaciones.
¡Hasta la próxima!