Los datos para probar

Los Arquitectos que trabajan cerca de los usuarios,
en sus ambientes reales, deben determinar los
datos de prueba de una solución durante
 la fase de diseño de la misma

Muchas veces, se tiene la idea de que las fases de desarrollo de una solución ocurren en cascada. Primero se concibe la idea, luego se diseña, luego se desarrolla, luego se prueba, luego se coloca en producción, luego se usa. Realmente la cosa no es así de fácil, sobre todo cuando hay el empeño en hacerlo bien y cuando la calidad del trabajo cuenta. Con esto en mente queremos hablar hoy de las pruebas, y más específicamente, de un detalle que a un gerente de servicios de información se le podría pasar inadvertido en algunos puntos del desarrollo de una buena solución de gestión en su sitio Web: los datos de prueba.

El desarrollo de soluciones de manejo de información que se hace hoy en día se caracteriza por su dinamismo. Siempre queremos que tengan usuarios rápido, pero es claro que para que nos vaya bien debemos probar su funcionamiento. Las preguntas son entonces ¿cuándo? y ¿con qué datos?.

Apenas se comienza a modelar o diseñar una solución hay que plantearse el tema de las pruebas. Dejarlo para luego puede implicar que nos planteamos el problema un poco tarde, obteniendo por ello dificultades e ineficiencias, que trabajando más proactivamente podríamos evitar.

En el ciclo de vida de una solución (ver) hay distintos tipos de pruebas. Las que realizamos como verificación de lo que estamos haciendo y las que realizamos como validación de lo que se ha hecho, trabajando junto con nuestros pretendidos usuarios. Las que prueban parcialmente aspectos modulares (pruebas unitarias) y las que prueban múltiples aspectos trabajando en forma integrada (pruebas de integración).

Un aspecto básico que debemos tener en cuenta es el momento correcto para la  génesis de las pruebas. Así pues debemos plantearnos la pregunta de cuándo, dónde y cómo deben generarse los datos de pruebas. Quizá pueda parecer sorprendente o exagerado, pero cuando se hacen bien las cosas los datos de prueba deben ser realizados cuando se está en la fase de diseño o modelado de la solución. ¿Por qué? Porque las personas que están realizando en ese momento el trabajo están en contacto directo con el problema, con los usuarios, con las condiciones de uso y saben qué es lo que se necesita y se espera que se haga como entrada y qué es lo que, en ese caso, debe obtenerse como salida.

Los constructores de la solución, arquitectos, informáticos o programadores deben realizar pruebas para asegurar que su creación está trabajando correctamente, pero para que sus pruebas sean pertinentes, realmente adecuadas, ellos deben usar data de prueba que las personas que levantaron la información, trabajando de cerca con el usuario, manejan. Los constructores conocen algunas restricciones, limitaciones y características de sus herramientas, procesos y métodos y aportan ello cuando hacen sus pruebas. Los datos de prueba introducidos por ellos pueden tener sentido, pero al mismo tiempo, ellos pueden no tener la misma consciencia sobre los contenidos de información específicos que tienen los arquitectos que trabajaron con los usuarios en el dominio de la aplicación.

Por ejemplo, algo tan simple como ¿cuán grande debe ser el tamaño de la caja que recibe un campo llamado asunto? es algo que en la construcción puede resolverse según la información que se tenga de los datos de prueba. Un campo Asunto, para un informático puede ser, razonablemente, de una línea, como las que siempre usa cuando escribe sus correos. Pero en una aplicación dada, por ejemplo, el Asunto en una correspondencia, un campo asunto debe ser algo bien descriptivo y debe por ello tener más de una línea. Este conocimiento lo tiene la persona que conceptualizó el sistema, al lado del usuario y es el a quien le corresponde definir los datos de prueba. Los constructores están obligados entonces a usar esa data y a incluirlas en su gestión de pruebas automatizadas.