1. Introducción

La Verificación y Validación (V&V) constituyen dos procesos fundamentales dentro de la Ingeniería de Software y forman parte de una estrategia más amplia de Aseguramiento de la Calidad del Software (Software Quality Assurance – SQA o QA).

Su propósito no consiste únicamente en encontrar errores. Una estrategia adecuada de V&V busca prevenir defectos, reducir riesgos, proporcionar evidencia objetiva sobre la calidad del producto y determinar si el software está preparado para ser utilizado en condiciones reales.

La distinción clásica entre ambos conceptos puede expresarse mediante dos preguntas:

Verificación:

¿Estamos construyendo el producto correctamente?

Determina si los artefactos generados durante el desarrollo cumplen con las especificaciones, estándares y diseños establecidos.

Validación:

¿Estamos construyendo el producto correcto?

Determina si el sistema desarrollado satisface las necesidades reales de los usuarios, clientes y demás partes interesadas.

Esta diferencia es importante porque un sistema puede estar correctamente construido desde el punto de vista técnico y, aun así, ser incorrecto desde el punto de vista del negocio.

Por ejemplo, un sistema bancario podría calcular perfectamente una comisión utilizando la fórmula especificada por el equipo técnico. Si dicha fórmula no representa la regla de negocio que realmente utiliza el banco, el sistema podría superar las actividades de verificación y, sin embargo, fallar durante la validación.

2. Verificación

La verificación consiste en evaluar productos intermedios y finales del desarrollo para determinar si cumplen con los requisitos, especificaciones y estándares establecidos.

Su objetivo principal es detectar inconsistencias lo antes posible.

La verificación puede aplicarse sobre:

• requisitos;
• historias de usuario;
• modelos de datos;
• diagramas UML;
• arquitectura;
• código fuente;
• contratos de API;
• scripts de base de datos;
• configuraciones;
• documentación técnica;
• casos de prueba.

Por esta razón, la verificación no requiere necesariamente ejecutar el sistema.

Ejemplo

Supongamos el siguiente requisito:

“El sistema deberá bloquear una cuenta después de cinco intentos consecutivos de autenticación fallidos.”

Durante la verificación se podría comprobar:

• que el requisito no sea ambiguo;
• que exista una regla correspondiente en el diseño;
• que el código implemente el límite de cinco intentos;
• que existan pruebas unitarias para los valores límite;
• que el mecanismo de bloqueo no pueda ser evadido;
• que exista trazabilidad entre requisito, implementación y pruebas.

La pregunta sigue siendo:

¿La implementación corresponde con lo especificado?

3. Validación

La validación determina si el producto construido satisface las necesidades y expectativas reales de sus usuarios y del negocio.

En este caso no basta con comprobar que el software coincide con una especificación. Es necesario determinar si esa especificación y su implementación producen un sistema realmente útil.

La validación normalmente requiere disponer de:

• prototipos;
• incrementos funcionales;
• versiones ejecutables;
• ambientes de pruebas;
• escenarios representativos del mundo real.

Ejemplo

Supongamos que una universidad solicita:

“El estudiante debe poder inscribirse a una materia mediante el sistema.”

El equipo puede implementar correctamente el formulario y cumplir técnicamente con la especificación.

Sin embargo, durante una prueba con estudiantes reales se descubre que el sistema permite seleccionar materias sin verificar prerrequisitos.

Técnicamente, la funcionalidad podría haber sido implementada según una especificación incompleta. Desde el punto de vista del usuario y del negocio, el sistema no satisface correctamente el proceso real de inscripción.

La validación busca descubrir precisamente este tipo de situaciones.

4. Comparación entre Verificación y Validación

Criterio	Verificación	Validación
Pregunta principal	¿Construimos correctamente el producto?	¿Construimos el producto correcto?
Objetivo	Cumplimiento de especificaciones	Satisfacción de necesidades reales
Orientación	Proceso y artefactos	Producto y usuario
Momento	Durante todo el desarrollo	Durante incrementos funcionales y versiones ejecutables
Técnicas	Revisiones, inspecciones, análisis estático y pruebas técnicas	Pruebas funcionales, UAT, usabilidad y escenarios reales
Participantes	Desarrollo, arquitectura, QA, seguridad	QA, usuarios, Product Owner, clientes
Evidencia	Cumplimiento técnico	Cumplimiento de objetivos de negocio
Riesgo principal	Construir incorrectamente	Construir algo que no resuelve la necesidad

La diferencia no significa que ambas actividades deban realizarse por separado. En proyectos modernos existe una interacción continua entre ellas.

5. Quality Assurance (QA)

Un error frecuente consiste en utilizar QA como sinónimo de “testing”.

El Aseguramiento de la Calidad (Quality Assurance) posee un alcance mayor.

QA comprende el conjunto de procesos, estándares, actividades y mecanismos utilizados para proporcionar confianza en que el software alcanzará el nivel de calidad esperado.

Por tanto:

Testing es una actividad dentro de QA, pero QA no se limita al testing.

QA puede incluir:

• definición de estándares de desarrollo;
• revisiones de código;
• gestión de requisitos;
• definición de criterios de aceptación;
• planificación de pruebas;
• automatización;
• gestión de defectos;
• métricas de calidad;
• auditorías;
• análisis de riesgos;
• gestión de configuración;
• integración continua;
• control de versiones;
• V&V.

Podemos visualizar la relación conceptualmente como:

Calidad de Software → QA → V&V → Testing

Aunque en organizaciones reales estas disciplinas pueden superponerse dependiendo de la metodología utilizada.

6. Quality Assurance y Quality Control

También resulta importante distinguir entre Quality Assurance (QA) y Quality Control (QC).

Quality Assurance

Tiene un enfoque principalmente preventivo.

Busca mejorar los procesos utilizados para desarrollar software y evitar que los defectos aparezcan.

Ejemplos:

• estándares de programación;
• Definition of Done;
• políticas de revisión de código;
• procedimientos de pruebas;
• pipelines de integración continua;
• criterios mínimos de cobertura;
• capacitación del equipo.

Quality Control

Tiene un enfoque principalmente detectivo.

Busca identificar defectos existentes en el producto.

Ejemplos:

• ejecución de pruebas;
• inspección de resultados;
• pruebas de regresión;
• identificación de defectos;
• comprobación de criterios de aceptación.

Una organización madura necesita ambos enfoques:

prevenir defectos cuando sea posible y detectar aquellos que inevitablemente aparezcan.

7. Actividades de Verificación

7.1 Revisión de requisitos

Los requisitos son analizados buscando:

• ambigüedades;
• contradicciones;
• información faltante;
• requisitos imposibles de comprobar;
• reglas de negocio incompletas.

Un requisito como:

“El sistema debe responder rápidamente.”

es difícil de verificar.

Una formulación verificable sería:

“El 95 % de las solicitudes deberá responder en menos de dos segundos bajo una carga concurrente de 500 usuarios.”

Ahora existe una condición objetiva que puede comprobarse.

7.2 Revisiones e inspecciones

Las revisiones permiten detectar problemas antes de ejecutar el software.

Pueden aplicarse a:

• arquitectura;
• código;
• diagramas;
• modelos de datos;
• historias de usuario;
• documentación;
• planes de prueba.

Entre las técnicas utilizadas encontramos:

• Peer Review
• Code Review
• Walkthrough
• Technical Review
• Formal Inspection

La diferencia principal está en el nivel de formalidad y estructura utilizado.

7.3 Análisis estático

El análisis estático examina el código sin ejecutar el programa.

Puede identificar:

• código duplicado;
• complejidad excesiva;
• variables sin utilizar;
• posibles vulnerabilidades;
• incumplimiento de estándares;
• errores potenciales;
• dependencias problemáticas;
• código muerto.

Herramientas como linters, analizadores de seguridad y plataformas de análisis de calidad pueden integrarse dentro del pipeline de desarrollo.

7.4 Pruebas unitarias

Evalúan unidades pequeñas del software, normalmente:

• funciones;
• métodos;
• clases;
• módulos.

Por ejemplo:

calcularDescuento(100, 10) → resultado esperado: 90

Permiten detectar errores rápidamente y proporcionan una red de seguridad para posteriores modificaciones.

7.5 Pruebas de integración

Comprueban la interacción entre componentes.

Por ejemplo:

Frontend
   ↓
API
   ↓
Servicio de negocio
   ↓
Base de datos

Cada componente puede funcionar correctamente de manera independiente y aun así producir errores cuando interactúa con los demás.

8. Actividades de Validación

8.1 Pruebas de sistema

Evalúan el comportamiento del sistema completo.

Por ejemplo:

Cliente realiza pedido
        ↓
Sistema calcula total
        ↓
Cliente realiza pago
        ↓
Sistema confirma transacción
        ↓
Inventario se actualiza
        ↓
Se genera comprobante

El objetivo consiste en comprobar el comportamiento completo y no únicamente componentes individuales.

8.2 Pruebas End-to-End

Las pruebas E2E simulan procesos completos similares a los realizados por usuarios reales.

Por ejemplo, en comercio electrónico:

Registro → inicio de sesión → búsqueda → carrito → pago → confirmación.

Son especialmente útiles para validar procesos críticos, aunque suelen ser más costosas y lentas que las pruebas unitarias.

8.3 User Acceptance Testing (UAT)

Las Pruebas de Aceptación del Usuario buscan determinar si el producto está preparado para satisfacer las necesidades del negocio.

Los escenarios deberían estar formulados desde la perspectiva del usuario.

Ejemplo:

Dado un cliente con una factura pendiente, cuando realiza el pago completo mediante QR, entonces la factura debe cambiar a estado “Pagada” y generarse el comprobante correspondiente.

El resultado de UAT puede convertirse en una condición para autorizar el paso a producción.

8.4 Pruebas de usabilidad

Evalúan aspectos como:

• facilidad de aprendizaje;
• eficiencia;
• claridad de navegación;
• accesibilidad;
• comprensión de mensajes;
• prevención de errores humanos.

Un sistema puede ser funcionalmente correcto y aun así presentar una experiencia de usuario deficiente.

8.5 Alpha y Beta Testing

Alpha

Se realiza en un entorno controlado, generalmente dentro de la organización responsable del producto.

Beta

Una versión suficientemente estable se proporciona a un grupo limitado de usuarios reales.

Permite detectar situaciones difíciles de reproducir internamente relacionadas con:

• dispositivos;
• redes;
• patrones reales de uso;
• configuraciones;
• expectativas de los usuarios.

9. V&V basada en riesgos

En proyectos reales es prácticamente imposible probar todas las combinaciones posibles de entradas, estados y escenarios.

Por esta razón, una estrategia moderna de calidad debe incorporar Risk-Based Testing (RBT) o pruebas basadas en riesgos.

El principio fundamental es:

La intensidad de las actividades de V&V debe ser proporcional al riesgo asociado al componente o funcionalidad.

El riesgo puede analizarse considerando dos variables principales:

Riesgo = Probabilidad × Impacto

Por ejemplo:

Evento	Probabilidad	Impacto	Riesgo
Error visual en una pantalla secundaria	Media	Bajo	Bajo
Error en cálculo de impuestos	Media	Alto	Alto
Pago duplicado	Baja	Crítico	Alto
Exposición de información privada	Baja	Crítico	Alto
Caída del sistema de autenticación	Media	Crítico	Muy alto

Esto permite priorizar los recursos de QA.

10. Gestión del riesgo dentro de V&V

La gestión de riesgos aplicada a calidad puede organizarse en cuatro etapas.

1. Identificación

Determinar qué puede fallar.

Ejemplos:

• pérdida de información;
• cálculos incorrectos;
• duplicación de transacciones;
• problemas de concurrencia;
• acceso no autorizado;
• indisponibilidad del servicio.

2. Análisis

Determinar:

• probabilidad de ocurrencia;
• impacto;
• detectabilidad;
• exposición al riesgo.

3. Mitigación

Diseñar controles para reducir el riesgo.

Por ejemplo:

Riesgo	Control
Pago duplicado	Idempotencia + pruebas de integración
Pérdida de datos	Backup + pruebas de restauración
Acceso no autorizado	Autorización + pruebas de seguridad
Error de cálculo	Pruebas unitarias + casos límite
Caída por carga	Pruebas de rendimiento

4. Monitoreo

Incluso después del despliegue deben observarse:

• logs;
• errores;
• métricas;
• incidentes;
• rendimiento;
• disponibilidad.

Por tanto, la calidad no termina cuando el sistema llega a producción.

11. Priorización de pruebas mediante riesgo

Supongamos que disponemos únicamente de dos días para probar un sistema de ventas.

Existen tres módulos:

A. Cambio de fotografía de perfil
B. Generación de facturas
C. Procesamiento de pagos

No sería razonable dedicar el mismo esfuerzo a los tres.

Una estrategia basada en riesgos probablemente establecería:

PRIORIDAD ALTA
Procesamiento de pagos

PRIORIDAD ALTA
Generación de facturas

PRIORIDAD BAJA
Fotografía de perfil

La razón no es que una funcionalidad sea “más importante” técnicamente, sino que el impacto potencial de un defecto es considerablemente diferente.

Este principio resulta esencial cuando existen restricciones de:

• tiempo;
• presupuesto;
• personal;
• infraestructura.

12. Trazabilidad

Una práctica importante dentro de V&V y QA es la trazabilidad de requisitos.

Consiste en mantener relaciones entre:

Necesidad del negocio
        ↓
Requisito
        ↓
Diseño
        ↓
Implementación
        ↓
Caso de prueba
        ↓
Resultado

Una herramienta habitual es la Requirements Traceability Matrix (RTM).

Ejemplo:

ID	Requisito	Implementación	Caso de prueba	Resultado
RF-01	Registrar cliente	ClienteService	TC-001	Aprobado
RF-02	Procesar pago	PaymentService	TC-014	Aprobado
RF-03	Anular venta	VentaService	TC-027	Fallido

La trazabilidad permite responder preguntas como:

¿Todos los requisitos fueron implementados?

¿Todos los requisitos tienen pruebas?

¿Qué requisito se ve afectado si modificamos este componente?

13. Niveles de pruebas y pirámide de testing

Una estrategia de QA equilibrada distribuye las pruebas en diferentes niveles.

Una representación habitual es:

             /\
            /E2E\
           /------\
          /Integr. \
         /----------\
        / Unitarias  \
       /______________\

Base: pruebas unitarias

Muchas pruebas.

• rápidas;
• económicas;
• específicas.

Nivel intermedio: integración

Cantidad moderada.

Comprueban contratos e interacción entre componentes.

Nivel superior: E2E

Menor cantidad.

Son más lentas, complejas y costosas, pero proporcionan evidencia sobre procesos completos.

La idea no consiste en eliminar las pruebas E2E, sino en utilizar cada nivel donde proporcione mayor valor.

14. Shift Left y Shift Right

La ingeniería moderna ha ampliado el concepto tradicional de QA mediante dos estrategias complementarias.

Shift Left

Significa introducir actividades de calidad más temprano en el ciclo de desarrollo.

Por ejemplo:

Requisitos → Diseño → Código → Testing → Producción
     ↑          ↑        ↑
     QA         QA       QA

Incluye:

• revisión temprana de requisitos;
• análisis de arquitectura;
• pruebas unitarias;
• análisis estático;
• seguridad desde desarrollo.

El objetivo es prevenir defectos antes de que sean costosos.

Shift Right

Extiende las actividades de calidad hacia producción.

Incluye:

• monitoreo;
• observabilidad;
• análisis de logs;
• métricas;
• alertas;
• pruebas controladas en producción;
• análisis de incidentes.

Esto reconoce una realidad importante:

Ningún entorno de pruebas reproduce perfectamente las condiciones de producción.

15. El costo del defecto

Una de las razones fundamentales para aplicar V&V tempranamente es el incremento del costo asociado a los defectos descubiertos en etapas posteriores.

Considérese un requisito incorrecto.

Si se detecta durante la revisión de requisitos, posiblemente sea suficiente modificar unas líneas del documento.

Si se detecta después de desarrollar el sistema, podría ser necesario modificar:

Requisito
   ↓
Diseño
   ↓
Código
   ↓
Base de datos
   ↓
Pruebas
   ↓
Documentación

Si llega a producción, además pueden aparecer:

• pérdida económica;
• indisponibilidad;
• pérdida o corrupción de información;
• incidentes de seguridad;
• incumplimientos contractuales;
• daño reputacional;
• costos de soporte.

Por ello, el objetivo no debe expresarse simplemente como:

“Encontrar bugs.”

Una visión más completa sería:

Detectar y prevenir defectos lo suficientemente temprano para reducir el riesgo técnico, económico y operacional asociado al software.

16. V&V dentro de metodologías ágiles

En enfoques tradicionales, V&V podía concentrarse en etapas específicas.

En Agile y DevOps se busca realizar estas actividades continuamente:

Historia de usuario
       ↓
Criterios de aceptación
       ↓
Desarrollo
       ↓
Code Review
       ↓
Pruebas unitarias
       ↓
Pruebas integración
       ↓
Build
       ↓
Testing
       ↓
UAT
       ↓
Deploy
       ↓
Monitoreo
       ↺

Esto introduce el concepto de Continuous Testing.

La calidad deja de ser responsabilidad exclusiva de un “departamento de QA” y pasa a convertirse en una responsabilidad compartida del equipo.

Desarrolladores, QA, arquitectos, analistas, Product Owners y usuarios aportan diferentes tipos de evidencia sobre la calidad del producto.

17. Ejemplo integrador: sistema de comercio electrónico

Supongamos que el requisito establece:

“Un cliente podrá pagar una compra mediante tarjeta y deberá recibir una confirmación únicamente cuando la transacción haya sido aprobada.”

Verificación

El equipo revisa:

• claridad del requisito;
• arquitectura de integración;
• contrato con la pasarela;
• código;
• manejo de errores;
• pruebas unitarias;
• pruebas de integración.

Validación

Se ejecuta el proceso completo:

Cliente
  ↓
Carrito
  ↓
Checkout
  ↓
Tarjeta
  ↓
Pasarela
  ↓
Confirmación
  ↓
Pedido generado

Se comprueba que el comportamiento corresponda con lo que el cliente espera.

Análisis de riesgo

Se identifican riesgos como:

• cobro duplicado;
• cobro aprobado pero pedido no creado;
• pedido creado sin pago;
• timeout de la pasarela;
• pérdida de conexión;
• respuesta duplicada del proveedor.

Debido a su impacto económico, estos escenarios reciben una prioridad de pruebas superior.

QA

QA establece además:

• criterios de aceptación;
• estrategia de pruebas;
• pruebas automatizadas;
• criterios mínimos para despliegue;
• registro y clasificación de defectos;
• métricas;
• monitoreo posterior al despliegue.

Así, V&V, QA y gestión de riesgos funcionan conjuntamente y no como disciplinas aisladas.

18. Conclusión

La Verificación y Validación constituyen mecanismos esenciales para generar evidencia sobre la calidad del software.

La verificación determina si el producto está siendo construido de acuerdo con sus especificaciones.

La validación determina si ese producto realmente satisface las necesidades para las cuales fue creado.

El Aseguramiento de Calidad (QA) proporciona el marco organizacional, técnico y metodológico dentro del cual estas actividades pueden ejecutarse sistemáticamente.

Finalmente, la gestión de riesgos permite decidir dónde concentrar los esfuerzos de calidad, reconociendo que los recursos disponibles son limitados y que no todos los defectos poseen las mismas consecuencias.

Por tanto, una estrategia moderna de calidad puede resumirse mediante cuatro preguntas:

1. ¿Qué debería hacer el sistema?
2. ¿Lo estamos construyendo correctamente?
3. ¿Resuelve realmente la necesidad del usuario?
4. ¿Qué puede fallar, cuál sería el impacto y qué evidencia necesitamos para aceptar ese riesgo?

La última pregunta representa un cambio importante de perspectiva: la calidad del software no consiste únicamente en demostrar que el sistema funciona, sino en alcanzar un nivel de confianza suficiente para utilizarlo bajo un nivel de riesgo aceptable.