Probar un software de empresa: las pruebas que hacer antes de usarlo cada día

La prueba de aceptación de un sistema de gestión falla casi siempre del mismo modo: se convoca a quien lo va a usar, se dice «probadlo», y las personas prueban las cosas que ya saben hacer. El software pasa. Después, el primer día de trabajo real, llega el pedido que hay que anular tras el envío, y eso no lo había probado nadie.

Probar significa escribir antes qué debe pasar, y después verificar que pasa. La diferencia entre las dos cosas está toda en la palabra «antes».

Un escenario de prueba no es «probar el programa»

Un escenario tiene cuatro partes, y si falta una la prueba no es ni repetible ni discutible.

• Los datos de partida: qué cliente, qué pedido, qué almacén, con qué valores.
• El rol: quién la ejecuta y con qué permisos.
• Los pasos: qué se hace, en el orden en que se hace.
• El resultado esperado: qué debe ser cierto al final, escrito antes de ejecutar.

El resultado esperado es la parte que se salta y es la única que cuenta. Sin él, la prueba termina con «me parece que funciona», que no es un resultado sino una impresión, y no se puede rebatir ni confirmar.

Un plan de pruebas: el encargo

Ejemplo ilustrativo sobre un módulo que gestiona encargos. Las pruebas se eligen para cubrir los tres tipos que siempre hacen falta: el caso normal, la excepción y lo que debe impedirse.

Las tres últimas filas son las que siempre se olvidan. Un sistema también se juzga por lo que rechaza, y el rechazo debe ser comprensible: una operación bloqueada sin explicación produce las mismas llamadas que un error.

Las pruebas en las que nadie piensa

• Las operaciones no autorizadas, probadas de verdad con el usuario limitado y no solo leídas en la tabla de permisos. También hay que comprobar impresiones y exportaciones, de las que los datos confidenciales salen más a menudo que de las pantallas.
• Los datos sucios: nombres con apóstrofos, direcciones larguísimas, importes a cero, adjuntos pesados, líneas duplicadas.
• Las interrupciones: la conexión que se cae a mitad de un guardado, dos personas que modifican el mismo registro, la misma operación enviada dos veces.
• Las integraciones cuando el otro sistema no responde: qué ve el usuario, qué queda pendiente, qué pasa cuando el otro sistema vuelve a estar disponible.
• Los momentos de cierre, si el software los trata de forma particular.

Clasificar los defectos en lugar de enumerarlos

Un listado de sesenta incidencias sin clasificar bloquea el proyecto: nadie sabe por dónde empezar y cada reunión se convierte en una negociación. Bastan cuatro categorías, acordadas antes de empezar.

• Bloqueante: impide trabajar y no existe una vía alternativa. Debe corregirse antes de la puesta en marcha.
• Grave: se puede trabajar, pero con un rodeo largo o con riesgo de error. Debe corregirse antes de la puesta en marcha o justo después, con una fecha.
• Menor: molestia, forma, texto poco claro. Se recoge y se arregla en bloque.
• Petición nueva: no es un defecto, es una función que no estaba prevista. Debe reconocerse como tal y evaluarse aparte.

La distinción entre la última categoría y las demás es la que salva el proyecto. Confundir una función que falta con un defecto traslada el coste a quien desarrolla y la fecha a todos, y convierte la prueba de aceptación en una obra sin fin.

Verificar las correcciones sin romper el resto

Cada corrección debe verificarla quien abrió la incidencia, no quien la resolvió, repitiendo la prueba original y no una parecida. Junto a ello hay que repetir un grupo reducido de pruebas sobre los recorridos principales: las correcciones arrastran efectos colaterales, y es normal que suceda.

Conviene fijar un número limitado de entregas durante la fase de pruebas —por ejemplo una a la semana— en lugar de corregir de forma continua. Probar un sistema que cambia bajo las manos hace que cada resultado sea poco fiable y cada incidencia discutible.

Puesta en marcha, soporte y vía de vuelta

1. Decidid cómo se empieza: todos juntos, un departamento cada vez, o en paralelo con el sistema anterior durante un período definido. El paralelo es seguro pero duplica el trabajo, así que hay que fijarle un plazo por escrito.
2. Estableced quién responde los primeros días, dónde se escribe y en cuánto tiempo se responde. Las dos primeras semanas generan más preguntas que el resto del año.
3. Definid la vía de vuelta: en qué condiciones se vuelve atrás, quién lo decide, y qué pasa con los datos introducidos mientras tanto. Si esta respuesta no existe, la puesta en marcha es una apuesta.

Lo que esta guía no cubre

Aquí se habla de aceptar procesos con un resultado previsible: dada una entrada, el sistema debe hacer una cosa precisa, siempre la misma. La verificación de sistemas que responden de forma probabilística —asistentes y contestadores automáticos, donde la misma pregunta puede recibir respuestas distintas y la corrección es una cuestión de grado— requiere un método diferente, tratado en otro lugar. También la elección de qué entra en la primera versión de un sistema de gestión tiene una guía propia.