Verificación vs validación: la pregunta que casi nadie sabe responder

Un equipo termina el sprint, corre la suite completa, todo pasa en verde. Despliegan con confianza. Una semana después el cliente escribe: "esto no es lo que pedimos". Nadie mintió. El software hace exactamente lo que dice el código, y el código hace exactamente lo que decía el ticket. El problema es que el ticket estaba mal desde el principio. Ese equipo verificó de manera impecable. Lo que nunca hizo fue validar.

Verificación y validación son las dos preguntas que sostienen toda la calidad de software, y se confunden todo el tiempo. Se resumen en una frase que vale la pena memorizar: verificación pregunta "¿construimos el producto bien?"; validación pregunta "¿construimos el producto correcto?". Suenan casi iguales. No lo son. Y entender la diferencia es lo que explica por qué QA de verdad empieza en el documento de requisitos, no en el editor de código.

01 · las dos preguntasConstruir bien no es lo mismo que construir lo correcto

La distinción es sencilla de enunciar y difícil de vivir. Verificación comprueba que el producto cumple sus especificaciones: que lo que construiste coincide con lo que estaba escrito que debías construir. Validación comprueba que esas especificaciones eran las adecuadas: que el producto resuelve la necesidad real del usuario. La primera mira hacia adentro, contra el documento. La segunda mira hacia afuera, contra la realidad.

La ISO/IEC/IEEE 29119, el estándar internacional de pruebas de software, lo separa con cuidado. Verificación es la confirmación, mediante evidencia objetiva, de que se han cumplido los requisitos especificados. Validación es la confirmación de que se han cumplido los requisitos para un uso previsto concreto [1]. Fíjate en el matiz: en un caso el juez es la especificación; en el otro, el uso real.

Verificación te dice si seguiste el plano. Validación te dice si el plano servía para algo.

Un ejemplo doméstico lo aterriza. Alguien pide una escalera para alcanzar el techo. El carpintero la construye con medidas perfectas, madera sólida, peldaños parejos: verificación superada, la escalera cumple el plano. Pero el techo estaba a cinco metros y la escalera mide tres. Validación fallida: se construyó bien un objeto que no resuelve el problema. Ninguna prueba de resistencia habría detectado eso, porque el defecto no está en la construcción sino en lo que se decidió construir.

02 · dónde vive cada unaLa verificación es interna; la validación mira al usuario

Como las dos preguntas apuntan a jueces distintos, se ejercen con técnicas distintas y en momentos distintos del ciclo. Confundirlas hace que un equipo crea que está cubierto cuando solo cubrió la mitad.

La verificación suele ser estática y temprana. Revisiones de requisitos, revisiones de diseño, inspecciones de código, análisis estático, pruebas unitarias y de integración: todo eso comprueba, sin necesidad de un usuario final, que cada pieza cumple lo que su especificación pedía. Es barata y se hace de manera continua, porque cada artefacto (el spec, el diseño, el módulo) se puede contrastar contra el anterior en cuanto existe.

La validación suele ser dinámica y tardía. Pruebas de sistema contra los escenarios reales, pruebas de aceptación con el cliente, betas, demos con usuarios de verdad. Aquí ya no basta con leer un documento: hay que ejecutar el producto en condiciones parecidas a las de su uso real y observar si de verdad resuelve la necesidad. Por eso la validación no se puede "adelantar" del todo; necesita algo funcionando y alguien real frente a ello.

De aquí sale una consecuencia práctica incómoda. Puedes tener una cobertura de pruebas del cien por ciento y un producto equivocado. La cobertura mide verificación: cuánto del código ejercitas. No dice nada sobre si ese código resolvía el problema correcto. Por eso "todas las pruebas pasan" nunca debería confundirse con "el producto está listo".

03 · por qué QA empieza en el specEl defecto más caro nace antes de escribir código

Si la validación pregunta si construimos lo correcto, entonces el momento más rentable para hacerse esa pregunta es antes de construir. Y ahí es donde verificación y validación se dan la mano en un punto que casi nadie mira: el documento de requisitos.

Un requisito se puede verificar (¿está bien escrito, es claro, es comprobable, no se contradice con otro?) y se puede validar (¿este requisito, aunque esté perfectamente redactado, es de verdad lo que el usuario necesita?). Cuando un equipo revisa el spec con las dos preguntas en la mano, atrapa el error más caro de todos: el requisito equivocado. Porque ese error, si sobrevive al spec, se propaga al diseño, al código y a las pruebas, y para cuando alguien lo nota en una demo ya costó semanas de trabajo bien hecho sobre una base mala.

Los datos clásicos de la ingeniería de software apuntan siempre en la misma dirección: cuanto más tarde se detecta un defecto, más cuesta corregirlo, y un defecto introducido en los requisitos y descubierto en producción puede costar órdenes de magnitud más que si se hubiera atrapado en la fase de requisitos [2]. Un requisito ambiguo revisado a tiempo se corrige con una conversación. El mismo requisito descubierto tras el lanzamiento se corrige con un rediseño.

Nada de esto quita valor a la verificación. Un producto que resuelve el problema correcto pero está mal construido tampoco sirve: se cae, es inseguro, es imposible de mantener. La lección no es elegir una pregunta sobre la otra, es que necesitas ambas y que fallan de maneras distintas. La verificación te protege de construir mal. La validación te protege de construir lo que no era. Un equipo que solo verifica entrega software impecable que a nadie le sirve; uno que solo valida entrega buenas ideas mal hechas.

La próxima vez que alguien diga "ya pasamos todas las pruebas", vale la pena preguntar cuál de las dos cosas se probó. Si solo se comprobó que el código cumple el spec, se verificó. Que el spec fuera el correcto sigue siendo una pregunta abierta, y es casi siempre la más importante.