Las Dos Preguntas Que Definen la Calidad
En software testing, dos preguntas fundamentales moldean todo lo que hacemos:
- Estamos construyendo el producto correctamente? (Verificacion)
- Estamos construyendo el producto correcto? (Validacion)
Estas dos preguntas — conocidas como Verificacion y Validacion, o V&V — representan dos perspectivas fundamentalmente diferentes sobre la calidad. Entender su distincion es esencial para cualquier tester, porque confundirlas lleva a construir software pulido que nadie quiere, o software util lleno de defectos.
Verificacion: Estamos Construyendo el Producto Correctamente?
La verificacion es el proceso de evaluar si un producto, componente o sistema cumple con sus especificaciones, requisitos y documentos de diseno. Verifica la conformidad con reglas y estandares definidos.
Piensa en la verificacion como una revision de calidad interna. Tienes un plano y estas verificando si la construccion coincide con ese plano. El plano podria estar equivocado — pero eso no es preocupacion de la verificacion.
Actividades de Verificacion
- Revisiones de requisitos: Cada requisito sigue la plantilla estandar? Es testeable? Hay contradicciones?
- Revisiones de diseno: La arquitectura coincide con los requisitos? Se aplican correctamente los patrones de diseno?
- Code reviews: El codigo sigue los estandares de codificacion? Se respetan las convenciones de nombres? Se implementa el manejo de errores?
- Testing unitario: Cada funcion retorna la salida esperada para las entradas dadas?
- Analisis estatico: El codigo tiene potenciales excepciones de puntero nulo, fugas de memoria o vulnerabilidades de seguridad?
- Walkthroughs e inspecciones: Los colegas confirman que el artefacto coincide con su especificacion?
Ejemplo de Verificacion
Requisito: “El formulario de login debe aceptar direcciones de email de hasta 254 caracteres.”
Verificaciones:
- El campo de email acepta 254 caracteres? (Testing de limites)
- Rechaza 255 caracteres? (Testing de limites)
- La columna de la base de datos permite 254 caracteres? (Revision de esquema)
- El API valida la longitud del email del lado del servidor? (Code review)
- Aparece el mensaje de error cuando se excede el limite? (Testing funcional)
Todas estas verifican si la implementacion coincide con la especificacion. Ninguna cuestiona si 254 caracteres es el limite correcto o si los usuarios necesitan emails tan largos.
Validacion: Estamos Construyendo el Producto Correcto?
La validacion es el proceso de evaluar si un producto satisface las necesidades y expectativas de sus usuarios y stakeholders. Verifica si el software resuelve el problema real que pretendia resolver.
Piensa en la validacion como una revision de calidad externa. No estas comparando contra un documento — estas comparando contra la realidad. Este software realmente ayuda a personas reales a realizar tareas reales?
Actividades de Validacion
- Testing de aceptacion de usuario (UAT): Usuarios reales prueban el producto contra sus flujos de trabajo reales
- Beta testing: Un grupo mas amplio de usuarios evalua el producto antes del lanzamiento general
- Testing de usabilidad: Observar a usuarios interactuando con el software para identificar puntos de friccion
- A/B testing: Comparar diferentes implementaciones para ver cual logra mejor los objetivos del usuario
- Revisiones de prototipos: Usuarios evaluan mockups antes de que comience el desarrollo
- Demos a stakeholders: Product owners confirman que la funcionalidad entregada coincide con su vision
Ejemplo de Validacion
Mismo formulario de login, perspectiva de validacion:
- Los usuarios prefieren iniciar sesion con email, o preferirian usar un numero de telefono?
- La casilla “Recordarme” es realmente util, o los usuarios esperan permanecer conectados por defecto?
- Los usuarios entienden los mensajes de error cuando falla el login?
- La autenticacion de dos factores esta agregando seguridad o solo frustrando a usuarios que abandonan el proceso?
Estas preguntas no se pueden responder leyendo una especificacion. Requieren observar el comportamiento real de los usuarios.
Tabla Comparativa
| Aspecto | Verificacion | Validacion |
|---|---|---|
| Pregunta | Construimos el producto correctamente? | Construimos el producto correcto? |
| Enfoque | Proceso y especificaciones | Necesidades y expectativas del usuario |
| Compara contra | Requisitos, docs de diseno, estandares | Uso real y objetivos del usuario |
| Metodos | Revisiones, inspecciones, analisis estatico, tests unitarios | UAT, beta testing, estudios de usabilidad |
| Quien lo realiza | Desarrolladores, testers, equipo QA | Usuarios, clientes, stakeholders |
| Cuando | Durante todo el desarrollo (shift-left) | Etapas posteriores, despues del build (shift-right) |
| Automatizable | Mayormente si | Parcialmente (A/B tests), mayormente juicio humano |
| Encuentra | Defectos (errores de implementacion) | Desajustes con expectativas del usuario |
La Analogia Clasica
Imagina que estas construyendo un puente:
La verificacion revisa:
- Las vigas de acero son del grado correcto?
- El concreto esta mezclado segun especificacion?
- Los pernos estan ajustados al torque correcto?
- El puente coincide con los planos de ingenieria?
La validacion revisa:
- El puente realmente resuelve el problema de trafico?
- El volumen de trafico esperado puede cruzar de forma segura?
- El puente esta en la ubicacion correcta?
- Los conductores encuentran intuitivo navegarlo?
Un puente puede pasar todas las verificaciones (construido perfectamente segun especificacion) y aun fallar la validacion (construido en la ubicacion incorrecta, resolviendo un problema que no existe).
Como V&V Trabajan Juntas
completos y consistentes?] R --> V2[Validacion: Los requisitos reflejan
necesidades reales del usuario?] D[Diseno] --> V3[Verificacion: El diseno
satisface los requisitos?] D --> V4[Validacion: El enfoque de diseno
es correcto para los usuarios?] I[Implementacion] --> V5[Verificacion: El codigo
coincide con el diseno?] I --> V6[Validacion: La funcionalidad trabaja
como esperan los usuarios?] T[Producto Entregado] --> V7[Verificacion: Todas las specs cumplidas?] T --> V8[Validacion: Usuarios satisfechos?] style V1 fill:#3b82f6,color:#fff style V3 fill:#3b82f6,color:#fff style V5 fill:#3b82f6,color:#fff style V7 fill:#3b82f6,color:#fff style V2 fill:#22c55e,color:#fff style V4 fill:#22c55e,color:#fff style V6 fill:#22c55e,color:#fff style V8 fill:#22c55e,color:#fff
Ambas actividades ocurren en cada fase del desarrollo, y ambas son necesarias. Un producto que pasa verificacion pero falla validacion es tecnicamente correcto pero inutil. Un producto que pasa validacion pero falla verificacion satisface necesidades del usuario pero es poco confiable.
El objetivo es pasar ambas: construir el producto correcto, y construirlo correctamente.
Ejemplo del Mundo Real
Considera un sistema de agendamiento de citas medicas:
Verificacion pasa, validacion falla: El sistema implementa perfectamente el requisito “los pacientes pueden agendar citas en bloques de 15 minutos.” Todas las pruebas pasan. Pero los pacientes reales quieren agendar por tipo de sintoma, y el sistema los obliga a saber que especialista necesitan. Los pacientes llaman a recepcion. El software es tecnicamente perfecto pero practicamente inutil.
Validacion pasa, verificacion falla: Las pruebas de usuario muestran que los pacientes aman la interfaz intuitiva y el enrutamiento basado en sintomas. Pero el sistema tiene una condicion de carrera: cuando dos pacientes reservan el ultimo turno simultaneamente, ambos reciben confirmacion. El software resuelve el problema correcto pero tiene defectos.
Ambas pasan: El sistema permite a los pacientes agendar por sintoma, los dirige al especialista correcto, maneja reservas concurrentes correctamente, y los pacientes realmente lo usan en lugar de llamar. Este es el objetivo.
Ejercicio: Clasifica Actividades de V&V
Para cada escenario, determina si es principalmente verificacion, validacion, o ambas:
- Un tester ejecuta el suite de pruebas automatizadas y confirma que las 500 pruebas pasan
- El equipo de producto observa a un grupo focal usar el nuevo flujo de checkout
- Un auditor de seguridad escanea el codigo en busca de vulnerabilidades OWASP Top 10
- El CEO demuestra el producto a un cliente empresarial clave para obtener feedback
- Un desarrollador ejecuta un linter que marca formato de codigo no conforme
- Un data scientist analiza grabaciones de sesiones de usuario para encontrar donde abandonan
- El equipo QA compara el formato de respuesta del API contra la especificacion OpenAPI
- Un grupo piloto de 100 usuarios prueba una nueva funcionalidad antes del lanzamiento completo
Pista
Preguntate: esta actividad compara contra una especificacion/documento (verificacion) o contra necesidades/expectativas del usuario (validacion)?Solucion
- Verificacion — Las pruebas automatizadas verifican la implementacion contra resultados esperados predefinidos
- Validacion — Los grupos focales evaluan si el producto satisface necesidades reales
- Verificacion — Escaneo contra un estandar definido (OWASP Top 10)
- Validacion — Recopilando feedback de un stakeholder real sobre si el producto satisface sus necesidades
- Verificacion — Verificando codigo contra un estandar de codificacion definido
- Validacion — Analizando comportamiento real del usuario para entender si el producto funciona para ellos
- Verificacion — Comparando implementacion contra un documento de especificacion
- Validacion — Usuarios reales evaluando la funcionalidad en la practica (beta testing)
Tips Profesionales
Tip 1: Los requisitos pueden ser “verificados” pero estar equivocados. Un requisito podria decir “la pagina de resultados de busqueda carga en menos de 5 segundos.” Verificas esto exitosamente. Pero los usuarios esperan resultados en menos de 1 segundo porque Google los entreno a esperarlo. Verificacion paso; validacion fallaria. Siempre cuestiona las specs, no solo pruebes contra ellas.
Tip 2: La validacion es mas dificil de automatizar — pero no imposible. Frameworks de A/B testing, herramientas de analitica y sistemas de feature flags permiten validar continuamente en produccion. El QA moderno no espera sesiones formales de UAT.
Tip 3: Los mejores testers hacen ambas simultaneamente. Mientras prueban una funcionalidad contra requisitos (verificacion), un tester habil tambien piensa “un usuario real realmente haria esto?” (validacion). Esta doble mentalidad detecta problemas que el testing con un solo enfoque no encuentra.
Puntos Clave
- La verificacion comprueba conformidad con especificaciones (“construir el producto correctamente”)
- La validacion comprueba conformidad con necesidades del usuario (“construir el producto correcto”)
- Ambas son necesarias — pasar una pero fallar la otra lleva a malos resultados
- La verificacion tiende a ser interna y basada en documentos; la validacion es externa y basada en usuarios
- El mejor enfoque de QA combina ambas perspectivas en cada fase de desarrollo
- Un producto perfectamente verificado que nadie quiere usar sigue siendo un fracaso