Pruebas durante la construcción de una solución

Cuando se trabaja desarrollando servicios que operan con
tecnologías de la información siempre hay que probar todo lo que se desarrolla. Además hay
que hacerlo múltiples veces. La caricatura es uno de esos chistes que circulan por Internet:
 "Razones para dejar de probar" (tomado de http://cartoontester.blogspot.com)

Una de las actividades fundamentales que se realiza durante la fase de desarrollo de una solución es la de pruebas. Los profesionales que trabajan con soluciones que implican o requieren del uso de tecnologías de la información saben que todo lo que se construye debe ser probado. Después de que se varía algo hay que volver a probar todo. Pero las pruebas no deben ser algo artesanal, aleatorio, esporádico. Antes bien deben ser actividades  metódicas, sistemáticas y regulares que dejan resultados predefinidos, y que por tanto permiten a gerentes, líderes y coordinadores medir sí o no se está convergiendo hacia una solución que funcionará y cumplirá con todos los requisitos diseñados previamente. ¿Qué se prueba? ¿Cuántas veces se prueba? ¿Cómo se prueba? ¿Con qué se prueba? Son preguntas cuyas respuestas deben estar claras para todos los gerentes y participantes del desarrollo de una solución.

Durante la construcción deben probarse la estructura de información, la funcionalidad, la navegación, la seguridad e incluso la estética. Estas pruebas toman tiempo y consumen recursos y por eso deben ser consideradas durante la planificación del proyecto. Cuando no son incluidas en la planeación es común que luego no se realizan cabalmente porque no se dispone de recursos o tiempo suficiente para hacerlas. Esto es uno de los errores más frecuentes y perniciosos de los desarrollos que no son realizados profesionalmente.

¿Con que datos se prueba? Como hemos señalado anteriormente (ver Los datos para probar), los datos que se usan para hacer pruebas deben producirse durante la fase de diseño. No debe trabajarse con lo que se le ocurre, sin mayores criterios, a las personas que construyen la solución. Debe garantizarse que todos los casos de uso (ver Conceptualización de una solución y casos de uso) se cumplen y que todos los requisitos funcionales son satisfechos. Para ello quienes mejor conocen estas exigencias previas a la fase de desarrollo deben establecer los datos de prueba. Si así se hace, la aplicación resultará en un producto confiable.

Durante todo el desarrollo, e incluso, más allá, durante las fases de implementación y producción siempre ocurren cambios o eventualidades en las condiciones en que se trabajan que requieren volver a probar. Si las pruebas se realizan manualmente, éstas tomarán mucho tiempo y serán poco confiables. Por esta razón en el desarrollo profesional siempre se incluye los recursos y el tiempo para establecer y realizar pruebas automáticas. Un computador puede hacer centenares de pruebas en unas horas, o en unos minutos, una persona no. Un computador puede distinguir con precisión un cambio en un elemento de una salida que una persona puede pasar por alto. Por eso las pruebas manuales no son recomendables: resultan incompletas, inexactas y sus resultados son finalmente aleatorios.

Obviamente no es lo automático en si mismo lo que da calidad a las pruebas. Las pruebas deben ser bien diseñadas, implementadas y realizadas. Cuando así se hace, es cuando cumplen con su función y garantizan la calidad. De otra forma serán poco más que un saludo a la bandera.

Ante un cambio de variable, una nueva característica, un cambio en uno de los elementos de la infraestructura, la mejor decisión es volver a probar todo. Incluso ante un cambio de apariencia completamente inofensiva, el texto de un mensaje, el cambio de posición de un elemento de la pantalla, es conveniente volver a probar. Si las pruebas son algo manual este desiderátum es irrealizable. Si las pruebas están diseñadas, establecidas para su ejecución automática, siempre entonadas y listas para realizarse, se pueden hacer muchas veces, se harán sin dificultad cada vez que hay un cambio y, en muchos casos, pueden hacerse como una actividad de fondo sin impactar las actividades principales, visibles frontalmente.