Los datos de prueba

Sorprendentemente, todavía escuchamos a responsables de proyectos que creen que armar los datos para una prueba consiste simplemente en “traerse un set de datos de producción”, o en todo caso, que el tester, al momento de ejecutar los casos, complete los formularios con lo primero que se le venga a la cabeza.

Parecen no comprender que es imposible realizar una buena prueba si el tester no controla los datos que utilizará en ella. Controlar los datos significa pensar de antemano con qué datos se ejecutará cada caso, escribirlos todos, incorporarlos al sistema en el momento oportuno y de la manera más eficiente, y tener conciencia en todo momento de qué datos tenemos, qué modificaciones deberían sufrir, y en qué estado deberían encontrarse al finalizar la ejecución de las pruebas.

Es cierto que en algunos casos necesitaremos contar con datos de producción, ya sea porque necesitamos fidelidad con las condiciones reales de operación del sistema, o porque es demasiado complejo generar los datos desde cero. Sin embargo, en la mayoría de los casos, los datos de producción son insuficientes, sobre todo para poner a prueba el sistema en condiciones diferentes del “camino correcto”, cuando necesitamos ver cómo reacciona ante una inconsistencia, ante errores de operación o ante ataques externos.

En este tipo de situaciones, necesitamos contar con datos especialmente diseñados, que nos garanticen poder crear las condiciones que requiere el caso de prueba. Estos datos deben ser generados por el tester, y controlados en todo momento. Hay que tener en cuenta que los datos pueden mejorar o empeorar un caso de prueba (1). Es decir, que el mismo caso de prueba, ejecutado con diferentes datos, puede arrojar resultados diferentes, y por consiguiente, un buen caso de prueba, ejecutado con los datos incorrectos, puede arruinarse y no cumplir su cometido.

Cuando hablamos de controlar los datos, también nos referimos a que el tester debe llevar un registro de qué datos utilizó en la ejecución de cada caso de prueba. De esta manera, ante la aparición de un defecto, podrá exhibir los datos con los que el defecto se detectó, a los efectos de facilitar su reproducción posterior. No se debe olvidar que muchos defectos sólo aparecen con determinados datos, o combinaciones de datos; si los datos se cambian, desaparece el defecto. Así, evitaremos que muchos defectos vuelvan de Desarrollo con el antipático comentario de “no se pudo reproducir”.

En suma, creemos que deberia dedicarse el mismo esfuerzo a diseñar los datos de prueba, que el que se dedica a diseñar los casos: los datos deben ser pensados y diseñados especialmente para cada caso de prueba, a continuación ser generados cuidadosamente, e incorporados al sistema en el momento oportuno, monitoréandolos en todo momento para verificar su estado. Una prueba donde el tester no controle los datos será una prueba insuficiente e incompleta.

(1) decimos que un caso de prueba es mejor cuantas más posibilidades tiene de sacar a la luz un defecto.