Verificar y validar

La verificación y la validación no deben confundirse

Entrando en el tema de la fase de implementación de soluciones de gestión de información vimos, el año pasado, que hay muchas variables imponderables que generan incertidumbres en relación a las dificultades y los tiempos que requieren los procesos. Observamos en esa oportunidad que, sin embargo, hay cuatro recomendaciones básicas que permiten ganar seguridad en la tarea de convertir una aplicación desarrollada en una solución en operación. La primera de estas recomendaciones es validar la solución en el ambiente de desarrollo antes de iniciar el movimiento hacia los ambientes de producción. Para comprender lo que ésto significa es necesario comenzar por establecer la diferencia entre la verificación y la validación, dando por descontado que ambas son actividades necesarias, que deben realizarse y que no deben confundirse.

La verificación es un proceso interno realizado por los desarrolladores de cada aspecto, de cada actividad, de cada tarea en cada dimensión del desarrollo de una solución. A los constructores les corresponden verificar que lo que recién desarrollaron está correcto. Vale decir, que hicieron bien su trabajo. Las preguntas pertinentes son, así pues, ¿Cómo verificar? ¿Contra qué verificar? ¿Quiénes deben verificar?

La manera de verificar es, en cierta formulación, tan obvia que pareciera trivial. “Se compara lo obtenido con lo que se debería obtener”. Sin embargo, más veces de las que nos imaginamos no es completamente claro lo que se debe obtener y, en ese caso, la obviedad desaparece. Como en condiciones normales lo que se quería obtener se plasma durante la fase de diseño bajo la forma de requisitos y casos de uso (ver Conceptualización de la solución y casos de uso), la verificación implica que se debe comparar lo obtenido con la lista de requisitos y las especificaciones de los casos de uso. La ventaja de éstos es que proporcionan una lista de ordenada de puntos de verificación.

¿Cuándo se debe verificar lo desarrollado? Normalmente los desarrolladores hacen verificaciones parciales en los distintos momentos de la construcción de una solución, pero es imperativo hacer una verificación completa justo antes de la validación ya que esta última involucrará otras personas y procesos. En principio las verificaciones pueden repetirse con frecuencia en la medida en que la construcción se realiza. Para ello es importante ayudarse con herramientas que permiten el trabajo automático, ya que la automatización de las pruebas disminuye el tiempo de la tarea, mejora su calidad y permite detectar tempranamente situaciones de falla. Siempre hay casos donde las pruebas automatizadas no son posibles, pero sus beneficios son demasiados como para prescindir de ellas cuando son posibles.

Las normas elementales de la calidad de procesos recomiendan, finalmente, que toda tarea realizada por una persona debe ser revisada por otra diferente ya que de esta forma disminuyen significativamente las probabilidades de que la solución que se construye transporte errores. No es suficiente y no debe considerarse en ningún caso una verificación formal una revisión realizada por la misma persona que hizo el trabajo, porque muy típicamente las personas repiten las mismas omisiones y las mismas secuencias cuando revisan lo que ellas realizaron, por lo que en la auto revisión las probabilidades de error aumentan.

En nuestro próximo post hablaremos de la validación, distinguiendo ésta de la verificación. Para el éxito de la fase de implementación de una solución ambas son necesarias.