¿Qué es un plan de pruebas? La página que dice lo que no vas a probar

Un plan de pruebas es un documento breve que dice qué se va a probar, qué no, quién lo hará, en qué entornos y qué tiene que ser cierto antes de que alguien empiece o pare. Se escribe antes de las pruebas, y su valor principal es el segundo punto de esa lista.

Cualquiera puede enumerar lo que piensa comprobar. Escribir lo que se deja de lado a propósito es la parte que evita la conversación de tres semanas después, esa en la que alguien dio por supuesto que algo estaba cubierto porque nadie dijo que no lo estaba.

Qué lleva dentro

Seis apartados concentran casi todo el valor, y cada uno puede ocupar unas pocas líneas.

• Alcance. Lo que cubre esta ronda de pruebas: qué funciones, qué versiones, qué plataformas.
• Fuera de alcance. Lo que deliberadamente no cubre, y por qué. El apartado más útil y el que más veces falta.
• Enfoque. Manual, automatizado o el reparto entre ambos, y a qué nivel.
• Entornos y datos. Dónde se ejecuta y contra qué, que es lo que decide qué se puede encontrar. Un plan que dice “staging” sin decir qué compilación y qué datos no está diciendo gran cosa.
• Criterios de entrada y de salida. Qué debe cumplirse antes de empezar a probar, y qué debe cumplirse antes de darlo por terminado.
• Riesgos. Lo que podría impedir que este plan funcione, nombrado mientras decirlo es barato.

Algunos planes añaden roles, un calendario y un proceso de defectos. Eso importa más cuanta más gente participa, y muy poco cuando sois dos.

Los criterios de salida son donde ocurren las discusiones

“Terminado” no es evidente, y un plan que no lo define produce una entrega que se discute el mismo día en lugar de acordarse por adelantado.

Flojo

Todos los errores importantes corregidos y las pruebas completadas

Mejor

Todos los casos de la suite de compra pasan, no hay defectos abiertos de severidad 1 o 2, y los tres defectos conocidos de severidad 3 están registrados con soluciones alternativas en las notas de la versión

El segundo lo puede comprobar alguien que no estuviera en la sala. El primero es un estado de ánimo.

Lo mismo vale para los criterios de entrada: acordar que las pruebas empiezan cuando la compilación pasa su prueba de humo le ahorra a quien prueba una tarde entera demostrando de cuarenta maneras que una compilación rota está rota.

Cuánto debe ocupar

Menos de lo que crees, y en proporción a cuánta gente tiene que estar de acuerdo.

Dos personas que prueban una función que ambas entienden necesitan un párrafo, y escribir más es teatro. Una entrega regulada con un auditor externo necesita el documento formal, porque alguien de fuera del equipo tiene que poder leer lo que se decidió. La mayor parte del trabajo queda en medio, y una página suele ser lo correcto.

La prueba que hay que aplicar: ¿cambiaría el comportamiento de alguien si este apartado no existiera? Si no, bórralo. Un plan que nadie lee es peor que ninguno, porque crea la creencia de que las pruebas estaban planificadas.

Dónde encaja entre los demás documentos

Un plan está un nivel por encima de las comprobaciones en sí.

• El plan dice que el flujo de compra se probará a mano en Chrome y Safari, y que el móvil queda fuera de alcance en esta ronda.
• Los casos de prueba dicen exactamente qué hacer y qué debería pasar.
• La suite de regresión dice qué se vuelve a comprobar porque antes funcionaba.
• Los criterios de aceptación dicen qué tenía que hacer la función en primer lugar, y se escribieron antes que todo lo demás.

Confundir el plan con los casos es el error habitual: un documento que enumera doscientos pasos no es un plan, es una suite con portada.

El proceso de defectos forma parte de él

Una línea que la mayoría de los planes se saltan, y cuesta más de lo que parece. Di cómo se reporta un defecto, adónde va y quién decide si detiene la entrega.

Sin eso, los hallazgos llegan en tres hilos de chat y una hoja de cálculo, quien los recopila se pasa el último día de la ronda persiguiendo detalles, y algo real se pierde entre el ruido. Nombra el destino y la forma de lo que entra en él, y enlaza la guía en lugar de repetirla: nuestra guía de informes de error existe para ser lo que enlazas.

Si quienes prueban son personas cuyo trabajo no es el software, la forma importa más, no menos. Pídeles qué pasó y qué esperaban, y deja que la herramienta cargue con la parte técnica.

La versión corta

Una página: qué está cubierto, qué no, cómo, dónde, qué tiene que cumplirse para empezar y para parar, y qué podría salir mal. Escrito antes de las pruebas, acordado por la gente a la que afecta y lo bastante corto como para que lo lean. El apartado que todo el mundo se salta, el de fuera de alcance, es el que evita la discusión.