Respuesta.

Verificación y validación son dos conceptos clave en las pruebas que determinan la conformidad del producto con las expectativas y requisitos.

Historia del asunto:

En la ingeniería de software surgió la separación de los conceptos de verificación (conformidad del producto con la especificación) y validación (conformidad con las expectativas del usuario) para describir dos caras diferentes de la calidad.

Problema:

Los especialistas confunden estos términos y aplican enfoques incorrectamente: prueban solo según las especificaciones, ignorando la experiencia del usuario, o viceversa, se basan únicamente en la lógica de "correcto/cómodo", olvidando los requisitos formales.

Solución:

Verificación (¿Estamos construyendo el producto correctamente?) — verificación de que el producto cumple con todos los requisitos de la especificación (especificaciones, documentación).
Validación (¿Estamos construyendo el producto correcto?) — asegurarse de que el producto resuelve la tarea del usuario y cumple con las expectativas reales.
Usar ambos enfoques: verificar según las especificaciones, validar a través de pruebas exploratorias "en vivo", escenarios de usuarios, pruebas de aceptación.

Características clave:

Verificación = verificación formal de requisitos.
Validación = empatía hacia el usuario, simulación de escenarios reales.
Ambas etapas son necesarias para una cobertura completa de errores.

Preguntas engañosas.

¿Qué significa "el producto pasó la verificación, pero falló la validación"?

Cumple con las especificaciones, pero no es conveniente, no resuelve la tarea del usuario y no es necesario en el mercado.

¿Se puede empezar la validación antes de la verificación?

No, primero debe verificarse un conjunto básico de requisitos, de lo contrario, la funcionalidad incompleta no permitirá evaluar la experiencia del usuario.

¿Falta de facilidad de uso parece un bug durante la verificación?

No, es un problema de UX que solo se revela en la etapa de validación de los escenarios de usuario.

Errores comunes y anti-patrones

Orientación solo a las especificaciones, ignorando UX.
Omitir pruebas de aceptación.
Comunicación insuficiente con quienes realmente usarán el producto.

Ejemplo de la vida real

Caso negativo

Se realizaron pruebas solo para verificar la conformidad con los requisitos de documentación. Después del lanzamiento, se descubrió que los usuarios no entienden la lógica de los pasos para completar el pedido, a pesar de la conformidad formal con los casos escritos.

Ventajas:

Todos los requisitos de la especificación se han implementado.

Desventajas:

Baja participación de los usuarios, quejas y abandono del producto.

Caso positivo

Se utilizó pruebas exploratorias y se organizó una prueba de UX con usuarios reales. Se identificaron incomodidades y se mejoró el proceso de checkout. Resultado: comentarios positivos, altas conversiones.