¿Qué es un caso de prueba? Cómo escribir uno que otra persona pueda ejecutar

Un caso de prueba es una sola comprobación, escrita para que alguien que no la redactó pueda ejecutarla y obtener la misma respuesta. Nombra un estado inicial, los pasos que hay que dar y lo que debería ocurrir. Si dos personas pueden ejecutarlo y no se ponen de acuerdo sobre si ha pasado, no está terminado.

Esa es toda la idea, y es la misma idea que un informe de error visto desde el otro lado. Un informe de error dice “así se consigue que algo falle”. Un caso de prueba dice “así se comprueba que va bien”.

Qué contiene

Seis partes, y solo tres son las interesantes.

• Un identificador para poder referirse a él en un informe de compilación o en una conversación
• Un título que diga qué se está comprobando, no qué se está pulsando
• Precondiciones: el estado en el que debe estar el mundo para que el paso uno tenga sentido
• Pasos, numerados, cada uno una acción
• Resultado esperado, lo bastante específico como para poder ser incorrecto
• Resultado real, que se rellena cuando se ejecuta

Los tres que deciden si funciona son las precondiciones, el resultado esperado y el título. Los pasos son fáciles. Saber qué estado da por supuesto la prueba, y qué significa “correcto” con la precisión suficiente para poder discutirlo, es el trabajo.

Escribir el título

Un título se lee dentro de una lista de doscientos, así que debería decir qué se verifica.

Débil

Probar la página de inicio de sesión

Mejor

El inicio de sesión se rechaza, con un mensaje, cuando la contraseña es incorrecta

El segundo te dice qué cubre, qué significaría un fallo y si duplica al de debajo. El primero no te dice nada, y dentro de seis meses nadie sabrá si cubre el mensaje de error o no.

Escribir los pasos

Numéralos y pon exactamente una acción en cada uno. La prueba no es el sitio para ahorrar palabras.

Título:         El inicio de sesión se rechaza, con un mensaje, cuando la contraseña
                es incorrecta
Precondiciones: Existe una cuenta confirmada para ada@example.com
Pasos:
  1. Abrir /login
  2. Escribir ada@example.com en el campo de correo
  3. Escribir wrongpassword en el campo de contraseña
  4. Pulsar Iniciar sesión
Esperado:       La página se queda en /login, muestra "El correo o la contraseña son
                incorrectos" y el campo de contraseña queda vacío

Fíjate en lo que el resultado esperado no dice: “aparece un error”. Tres implementaciones distintas cumplen esa frase y dos de ellas están mal. También nombra lo que no debería haber ocurrido, que no haya navegación, porque una prueba que solo comprueba el mensaje pasa igualmente en una página que muestra el mensaje y aun así inicia la sesión.

Qué estropea un caso de prueba

Depende de la prueba anterior. Un caso que solo pasa si antes se ejecutó el anterior no puede ejecutarse solo, no puede reordenarse y se cae en bloque cuando algo temprano se rompe. Cada caso monta sus propias precondiciones.

Comprueba seis cosas. Cuando falla, aprendes que una de seis cosas está mal. Divídelo.

Describe la interfaz en lugar del comportamiento. “Pulsar el botón azul de arriba a la derecha” se rompe cuando el botón se mueve; “Enviar el formulario” no.

Su resultado esperado es un encogimiento de hombros. “Funciona correctamente”, “según lo diseñado”, “sin errores” - todo eso significa que decide quien lo ejecuta, que es justo lo que un caso de prueba existe para evitar.

Prueba lo que no puede fallar. Un caso que verifica que un encabezado estático dice las palabras correctas cuesta tiempo en cada ejecución para siempre. Gasta el esfuerzo donde vive el comportamiento.

Casos manuales y casos automatizados

La misma disciplina, distinta economía. Un caso automatizado se ejecuta en cada compilación y tiene que ser preciso o será inestable; un caso manual lo ejecuta una persona que puede aplicar criterio, que es a la vez su fuerza y la razón por la que dos personas sacan dos respuestas de uno vago.

Escribe casos manuales para lo que necesita criterio - si este diseño se ve mal, si este mensaje tiene sentido - y automatiza lo que tiene una entrada conocida y una respuesta conocida. Y deja los manuales más cortos de lo que crees: un caso de quince pasos se lo salta por la mitad cualquiera que lo ejecute por novena vez.

Cuando uno falla

Un caso de prueba fallido es el comienzo de un informe de error, y empieza por delante de la mayoría: los pasos ya están escritos, el resultado esperado ya está enunciado y ambos están en un lenguaje sobre el que alguien puede actuar.

Lo que no lleva es el contexto de la máquina en la que falló - el navegador, la consola, las peticiones que hay detrás de la página. Esa es la distancia entre “el caso de prueba 47 ha fallado” y un informe con el que un desarrollador puede trabajar.

Adjunta el identificador del caso al informe y los dos quedan conectados: quien lo arregle puede ejecutar la misma comprobación, y quien ejecute la comprobación en la siguiente versión verá que una vez falló. La guía de informes de error cubre el resto de lo que necesita ese informe.

La versión corta

Una comprobación por caso. Precondiciones que él mismo monta. Pasos que otra persona pueda seguir. Un resultado esperado lo bastante específico como para que dos personas no puedan discutir sobre si ocurrió. Todo lo demás es formato.