En Testing de Software se usan dos conceptos muy importantes: verificación y validación. Ambos están relacionados con la calidad, pero no significan lo mismo.
La verificación busca comprobar si el producto fue construido de acuerdo con lo especificado. La validación busca comprobar si el producto realmente satisface la necesidad del usuario o del negocio.
Una frase clásica resume la diferencia:
Comprender esta diferencia ayuda a evitar un error frecuente: crear un sistema técnicamente correcto, pero poco útil para quien debe usarlo.
La verificación consiste en comprobar que un artefacto del proyecto cumple con especificaciones, reglas, estándares o criterios definidos. Puede aplicarse a requisitos, diseños, código, configuraciones, documentación y casos de prueba.
En términos simples, la verificación pregunta si algo fue hecho correctamente según lo acordado.
Ejemplos de verificación:
La verificación puede realizarse con el sistema ejecutándose o sin ejecutarlo, dependiendo del artefacto que se revise.
La validación consiste en comprobar que el producto satisface la necesidad real del usuario, del cliente o del negocio. No alcanza con cumplir la especificación si la especificación no resuelve el problema correcto.
La validación pregunta si el producto es adecuado para su propósito.
Ejemplos de validación:
La validación suele requerir una mirada más cercana al usuario, al contexto y al valor esperado del producto.
La diferencia central es el tipo de pregunta que hacemos:
| Concepto | Pregunta principal | Foco | Ejemplo |
|---|---|---|---|
| Verificación | ¿Cumple con lo especificado? | Correctitud respecto de requisitos, diseño o estándares. | El descuento calculado es exactamente el 15% indicado en el requisito. |
| Validación | ¿Resuelve la necesidad real? | Utilidad, valor y adecuación al usuario o negocio. | El descuento permite aplicar correctamente la promoción que el negocio necesita ofrecer. |
Un producto puede estar verificado y aun así no estar validado. Es decir, puede cumplir la especificación, pero no resolver el problema correcto.
Supongamos que se desarrolla un formulario de registro de usuarios. El requisito dice:
Algunas preguntas de verificación serían:
Algunas preguntas de validación serían:
Ambos grupos de preguntas son importantes. Verificar sin validar puede producir una funcionalidad correcta en papel, pero poco útil en la práctica.
La verificación puede incluir actividades estáticas y dinámicas. Las actividades estáticas revisan artefactos sin ejecutar el sistema. Las dinámicas ejecutan software y comparan resultados.
Ejemplos de actividades de verificación:
La verificación ayuda a detectar desviaciones respecto de lo acordado.
La validación se concentra más en confirmar valor y adecuación al uso real. Algunas actividades posibles son:
La validación ayuda a responder si el producto sirve para el propósito que motivó su construcción.
Un error común es construir exactamente lo que se especificó, pero descubrir tarde que lo especificado no era lo que el usuario necesitaba.
Ejemplo: una empresa pide un reporte mensual de ventas en formato PDF. El equipo desarrolla el reporte, calcula bien los totales, respeta el diseño y permite descargarlo. Desde la verificación, todo parece correcto.
Pero luego los usuarios explican que necesitan filtrar por vendedor y exportar a hoja de cálculo para hacer análisis internos. El PDF cumple el requisito escrito, pero no resuelve la necesidad real.
También puede ocurrir lo contrario: una idea parece útil para el usuario, pero la implementación tiene errores. En ese caso, la necesidad puede estar bien identificada, pero el producto no está construido correctamente.
Ejemplo: los usuarios necesitan consultar el historial de pagos. La funcionalidad es valiosa y responde a una necesidad real. Sin embargo, el sistema muestra pagos duplicados o no ordena correctamente las fechas.
La funcionalidad puede estar validada como idea, pero falla en la verificación porque no cumple correctamente las reglas esperadas.
Por eso no conviene elegir entre verificación o validación. Necesitamos ambas.
Los requisitos y criterios de aceptación son fundamentales para verificar y validar. Un buen criterio de aceptación permite comprobar si una funcionalidad cumple lo acordado.
Ejemplo de criterio de aceptación:
Este criterio ayuda a verificar el comportamiento esperado. Pero además debemos validar si ese flujo es suficiente para el usuario real. Tal vez también necesite recordar sesión, recuperar contraseña o iniciar sesión con otro proveedor.
La verificación se apoya en lo definido. La validación cuestiona si lo definido es adecuado.
Tanto la verificación como la validación pueden incluir pruebas manuales y automatizadas, pero cada enfoque tiene usos distintos.
| Actividad | Puede automatizarse | Comentario |
|---|---|---|
| Verificar un cálculo | Sí | Es ideal para pruebas repetibles con resultado esperado claro. |
| Verificar que una API devuelva un campo obligatorio | Sí | Puede ejecutarse en cada cambio del sistema. |
| Validar si una pantalla es comprensible para usuarios nuevos | No completamente | Requiere observación, interpretación y feedback humano. |
| Validar si una funcionalidad resuelve una necesidad de negocio | No completamente | Requiere participación de negocio o usuarios representativos. |
La automatización es muy útil para verificaciones repetibles, pero no reemplaza la validación humana del valor y la utilidad.
Ambos conceptos pueden aparecer en varias etapas del ciclo de vida:
| Etapa | Verificación | Validación |
|---|---|---|
| Requisitos | Revisar que sean claros, completos y testeables. | Confirmar que describen una necesidad real. |
| Diseño | Comprobar que el diseño respeta reglas y estándares. | Revisar si el flujo será útil y comprensible. |
| Desarrollo | Ejecutar pruebas técnicas contra especificaciones. | Confirmar con negocio que el comportamiento construido tiene sentido. |
| Pruebas finales | Ejecutar casos funcionales y de regresión. | Realizar pruebas de aceptación o validación de usuario. |
| Producción | Monitorear funcionamiento y errores. | Medir si la funcionalidad realmente se usa y aporta valor. |
Algunos errores frecuentes al trabajar con verificación y validación son:
La solución no es agregar más pruebas sin criterio, sino mejorar la comunicación, aclarar expectativas y combinar ambas miradas.
Para aplicar bien verificación y validación conviene:
La combinación de buenas especificaciones, pruebas y feedback real reduce la distancia entre lo construido y lo necesario.
Verificación y validación son dos perspectivas complementarias. La verificación nos ayuda a comprobar si el producto cumple lo definido. La validación nos ayuda a confirmar si lo definido y construido realmente resuelve el problema correcto.
Un equipo que solo verifica puede entregar software correcto según documentos, pero poco útil. Un equipo que solo valida ideas sin verificar detalles puede entregar una solución valiosa, pero defectuosa. La calidad aparece cuando ambas actividades trabajan juntas.
En el próximo tema estudiaremos requisitos, criterios de aceptación y casos de uso, elementos fundamentales para saber qué debe probarse y cómo definir resultados esperados claros.