La validación de una solución

La validación en un proceso crítico, interactivo entre grupos diferentes,
una actividad neurálgica donde  hay encuentro de culturas
y presiones para finalizar. Por ello para su ejecución exitosa
se requiere una acertada planificación, acuerdos y métodos

Retomando la conversación sobre la fase de transición o de implementación de una solución, dentro del ciclo de vida de una aplicación de gestión de información, hemos comentado que hay dos actividades que marcan el paso del desarrollo a la implementación, de la construcción de la solución a la transición que permitirá finalmente su entrada en producción. Se trata de la verificación y la validación. La primera es un proceso al interior del grupo de desarrolladores y la describimos la semana pasada. La segunda, la validación, de la cual hablaremos hoy, es una actividad intergrupal delicada y crucial cuya complejidad para ser bien llevada requiere que se tomen las precauciones necesarias.

Si la verificación es un proceso interno que realizan los constructores de la solución, la validación es un proceso de interacción que debe involucrar a desarrolladores, usuarios y contrapartes. El grupo de personas que interactúan en ella trasciende así los límites del equipo de desarrollo y probablemente las fronteras institucionales ya que en muchos casos el personal de desarrollo es parte de una empresa externa a la institución destinataria. Esto significa que, independientemente de los temas técnicos, hay un encuentro de culturas y por ello se debe gestionar un lenguaje común que explicite, sin ambigüedades, los puntos críticos de los acuerdos que serán necesarios.

Es importante realizar la validación bajo un plan de trabajo predefinido y, una vez más, los casos de uso (Ver), convertidos en casos de prueba, suelen ser la guía necesaria para validar que la solución desarrollada está conforme a lo acordado.

Si no se realiza de esta manera pueden hacerse pruebas incompletas que lleven a conclusiones de satisfacción demasiado rápidas, pero más temprano que tarde hay que enfrentar problemas cuando cualquier disconformidad con lo pretendido salta a la vista. También se dan en ocasiones otros casos diferentes, por ejemplo la exageración del significado de un punto de falla encontrado sin tomar en cuenta lo aislado o lo especifico de ése, o que comiencen a salir nuevos requisitos formulados ad-hoc porque a algunos usuarios se les ocurren nuevas cosas, a veces intrascendentes, en ese momento.

Como puede haber presión financiera, de meta cumplida, o de calendario, estos inconvenientes pueden puede darse sin la cordialidad necesaria en el trabajo técnico. La manera de evitar estos problemas, así pues, está en los casos de uso y en los acuerdos acerca de los métodos.

En forma adicional a los casos de uso, es normal que la validación incluya el recorrido de todas las opciones de menú para asegurar que el comportamiento es uniforme y consistente. Cuando se hace bien se deben registrar todas las consultas realizadas y todos los resultados obtenidos con el objeto de poder repetir la validación en forma automática en caso de que haya algunas no conformidades que requieran volver a reiniciar la validación o en caso de que más adelante se necesite realizar un proceso de migración.
Es importante destacar que el recorrido de todos los casos de uso, de todas las opciones de menú y de las comunidades de trabajo involucradas críticamente en la aplicación es una tarea que puede consumir tiempo y así debe considerarse en la planificación.

En síntesis, cuando no hay un plan de trabajo definido para la validación el resultado es cualquier cosa. No se puede concluir nada acerca de la calidad y esto, en la práctica, se traduce en que más temprano que tarde aparecen problemas que los usuarios reportarán a los desarrolladores y que eventualmente, si no son bien llevados,  se traducen en tensiones entre los equipos involucrados. Así podemos concluir en que una verificación mal realizada o el no definir y acordar desde el principio lo que se realizará como validación es activar una bomba de tiempo potencial.