Una funcionalidad de búsqueda que devuelve resultados en 3 segundos pasa la verificación: cumple el requisito. Falla la validación: los usuarios la comparan con los 0.3 segundos de Google y la encuentran inaceptablemente lenta, aunque el spec nunca dijo lo contrario. Este artículo cubre la distinción entre ambas, dónde cae cada actividad de testing en el espectro, y por qué detectar solo los fallos de verificación deja toda una categoría de defectos sin tocar.
Las definiciones cortas
Verificación comprueba si el producto se ajusta a sus especificaciones. ¿Coincide con lo que se documentó, diseñó y acordó? Validación comprueba si el producto satisface las necesidades reales del usuario. ¿Resuelve el problema real para el que fue construido?Puedes tener un producto que pasa la verificación pero falla la validación: funciona exactamente como se especificó, pero la especificación estaba mal: no hace lo que los usuarios realmente necesitan.
También puedes tener un producto que pasa la validación pero falla la verificación: los usuarios lo adoran y funciona muy bien, pero tiene funcionalidades no documentadas, agujeros de seguridad, o comportamientos que difieren del spec.
Verificación: ¿coincide con el spec?
Las actividades de verificación generalmente se realizan sin ejecutar el software. La pregunta es: ¿lo que construimos coincide con lo que se acordó?
Cómo se ve la verificación
#### Revisiones de documentos
¿El documento de requisitos cubre todas las funcionalidades acordadas? ¿El spec de diseño es consistente con los requisitos? ¿Los casos de prueba cubren todos los requisitos?
#### Revisiones de código
¿El código implementa lo que dice el documento de diseño? ¿Se aplican los patrones de seguridad del estándar de codificación?
#### Inspección
Recorrer juntos los requisitos, el diseño y la implementación. ¿Todo está alineado?
#### Revisión de prototipo/wireframe
¿El wireframe de UI coincide con las historias de usuario acordadas?
El objetivo
Encontrar defectos en los documentos y diseños antes de que se construya o pruebe el software. Es más barato corregir un requisito incorrecto en papel que corregirlo después de 3 sprints de desarrollo.
Validación: ¿resuelve el problema real?
La validación se realiza ejecutando el software, generalmente a través de testing real. La pregunta es: ¿este producto funciona para las personas para las que fue construido?
Cómo se ve la validación
#### Testing de aceptación del usuario (UAT)
Usuarios reales o stakeholders prueban el software contra sus flujos de trabajo reales. La pregunta clave: "¿Hace esto lo que yo necesitaba que hiciera?"
#### Testing del sistema
Probar el sistema completo e integrado contra los requisitos, pero también contra los objetivos del usuario. ¿Todo funciona realmente de principio a fin para casos de uso realistas?
#### Testing beta
Un subconjunto de usuarios reales usa el producto en su entorno real. Descubre brechas que el testing basado en spec omitió porque el spec no capturó el uso real.
#### Testing de usabilidad
¿Pueden los usuarios realmente lograr sus objetivos con esta interfaz? Aunque sea técnicamente correcto, ¿es usable?
El objetivo
Confirmar que el software entrega valor real. Una funcionalidad puede ser técnicamente correcta y completamente inútil.
Un ejemplo concreto
Imagina un requisito:
"El campo de búsqueda debe devolver resultados en 3 segundos."Pregunta de verificación: ¿La implementación coincide con este requisito? Probamos: ejecutamos una búsqueda, medimos el tiempo, confirmamos que es menos de 3 segundos. Pasa. Pregunta de validación: ¿Esto resuelve el problema real del usuario? Descubrimos: los usuarios están buscando en catálogos de productos enormes y 3 segundos se siente inaceptablemente lento cuando Google devuelve resultados en 0.3 segundos. Aunque el spec decía 3 segundos y el código cumple eso, la validación falla.
La especificación estaba mal. La verificación no detectó nada. La validación detectó todo.
Por eso no puedes basarte únicamente en la verificación: el spec es tan bueno como las personas que lo escribieron.
Otro ejemplo: validación de formulario
Requisito: "El campo de contraseña no debe aceptar menos de 8 caracteres."
Verificación: Probamos que una contraseña de 7 caracteres es rechazada. Lo es. Validación: Un usuario real intenta usar su contraseña habitual de 6 caracteres, la rechazan, intenta crear una nueva de 8 caracteres, pero el mensaje de error dice solo "Entrada inválida" sin explicación. Se rinde y no se registra. La validación falla: el producto no ayuda a los usuarios a lograr el objetivo de registrarse.El código era correcto. El requisito era demasiado estrecho. No contempló la experiencia del usuario ante el mensaje de error.
Cómo aparecen en el ciclo de desarrollo
| Fase | Actividad | ¿Verificación o validación? |
|------|-----------|----------------------------|
| Requisitos | Revisión de requisitos: verificar completitud y consistencia | Verificación |
| Diseño | Revisión de diseño: verificar que el diseño coincida con los requisitos | Verificación |
| Desarrollo | Revisión de código: verificar que el código coincida con el diseño | Verificación |
| Testing | Tests unitarios: verificar que los componentes funcionen según lo especificado | Verificación |
| Testing | Tests de integración: verificar que los módulos trabajen juntos | Verificación |
| Testing | Tests del sistema: verificar que el sistema completo cumpla los requisitos | Ambos |
| Testing | UAT: verificar que usuarios reales puedan lograr objetivos reales | Validación |
| Release | Testing beta: uso en el mundo real | Validación |
La mayor parte de lo que hacen los QA engineers en el trabajo diario es una mezcla de ambas: ejecutan tests contra requisitos (verificación) mientras también piensan si la funcionalidad realmente funciona para usuarios reales (validación).
Por qué importa esta distinción
Bugs por fallos de verificación
La implementación no coincide con el spec. Un botón no hace lo que el requisito dice que debería. Un cálculo es incorrecto. Un campo acepta valores que no debería.
Bugs por fallos de validación
El spec estaba incompleto o era incorrecto. La funcionalidad funciona según lo diseñado pero falla en escenarios de usuarios reales. Mensajes de error faltantes, flujos confusos, rendimiento técnicamente aceptable pero prácticamente terrible.
Un buen QA detecta ambos. La ejecución pura de tests basados en spec detecta fallos de verificación. El testing exploratorio, las revisiones de usabilidad y el UAT detectan fallos de validación.
La versión para entrevistas
Si te preguntan esto en una entrevista:
Verificación = "¿Estamos construyendo el producto correctamente?" Conformidad con las especificaciones, típicamente estática (revisiones, walkthroughs) o testing en etapas tempranas contra requisitos documentados. Validación = "¿Estamos construyendo el producto correcto?" Confirmación de que el software satisface las necesidades del usuario, típicamente ejecutando el software en condiciones realistas (UAT, testing beta, testing de usabilidad).La analogía clásica: un mapa puede ser preciso (verificación: representa correctamente el terreno) pero inútil (validación: muestra el destino equivocado). Necesitas tanto un mapa correcto como el destino correcto.
Ambos conceptos son relevantes para el trabajo de todo QA engineer, aunque nunca uses los términos explícitamente. Cada vez que verificas "¿esto coincide con el requisito?", estás haciendo verificación. Cada vez que preguntas "¿esto realmente funciona para un usuario real?", estás haciendo validación. Los mejores testers mantienen ambas preguntas corriendo simultáneamente.
→ See also: Testing Caja Negra vs Caja Blanca: Guía Clara para Ingenieros QA | Pruebas de Aceptación: Qué Son, Quién Las Hace y Cómo | ¿Qué Es el Testing Manual? La Guía Completa para 2026
