Un equipo puede construir software que coincida perfectamente con su especificación y, aun así, enviar el producto equivocado. También pueden construir el producto exactamente correcto sobre un código lleno de defectos. Esos dos fallos tienen nombres: el primero es un problema de verificación, el segundo es un problema de validación. Confundir ambos es cómo los procesos de calidad terminan estando ocupados pero siendo ineficaces.
Esta guía define ambos términos, expone las diferencias y muestra dónde encaja cada uno en un flujo de trabajo de prueba de API con Apidog.
¿Qué es la verificación?
La verificación pregunta: ¿estamos construyendo el producto correctamente?
Verifica que una pieza de software se ajusta a su especificación, su diseño y sus estándares. La verificación compara el trabajo con la intención documentada. No pregunta si esa intención era correcta; solo pregunta si la implementación coincide con ella.
La verificación ocurre continuamente, a lo largo del desarrollo, no al final. Las actividades de verificación típicas incluyen:
- Revisiones de código y recorridos
- Análisis estático y linting
- Revisiones de diseño y arquitectura
- Comprobaciones de esquemas y contratos
- Pruebas unitarias que confirman que una función hace lo que su firma promete
La característica clave es que la verificación es principalmente interna. Compara un artefacto con otro artefacto: código con diseño, respuesta con esquema, implementación con especificación. No se requiere un usuario real. Si la especificación dice que el endpoint devuelve un 201 con un encabezado Location, la verificación confirma que hace exactamente eso.
¿Qué es la validación?
La validación pregunta: ¿estamos construyendo el producto correcto?
Verifica que el software realmente satisface las necesidades del usuario y resuelve el problema real, independientemente de lo que decía la especificación. La validación compara el trabajo con la realidad y la intención de uso, no con un documento.
La validación tiende a ocurrir más tarde, una vez que hay algo que un usuario o interesado puede probar. Las actividades de validación típicas incluyen:
- Pruebas de aceptación de usuario
- Programas beta y pruebas de usabilidad
- Pruebas de extremo a extremo de flujos de trabajo completos
- Demostraciones y aprobación de los interesados
La característica clave es que la validación está orientada hacia el exterior. Pregunta si el producto terminado es útil y correcto en su contexto. Una API puede pasar todas las comprobaciones de verificación, ajustarse perfectamente a su especificación OpenAPI, y aun así fallar la validación porque la especificación misma resolvió el problema equivocado; el modelo de paginación es inutilizable, o el flujo de autenticación no se ajusta a cómo los clientes realmente se integran.
Validación vs. verificación: las diferencias
| Dimensión | Verificación | Validación |
|---|---|---|
| Pregunta central | ¿Estamos construyendo bien el producto? | ¿Estamos construyendo el producto correcto? |
| Compara contra | Especificación, diseño, estándares | Necesidades del usuario, uso en el mundo real |
| Momento | Continuo, a lo largo del desarrollo | Más tarde, una vez que algo es utilizable |
| Métodos típicos | Revisiones, análisis estático, pruebas unitarias, comprobaciones de esquema | Pruebas de aceptación, beta, de extremo a extremo, demos |
| Dirección | Interna: artefacto vs. artefacto | Externa: producto vs. realidad |
| Detecta | Defectos, desviaciones de la especificación, desvío de contrato | Requisitos incorrectos, mal ajuste, brechas de usabilidad |
| Costo de omitir | Código con errores que coincide con una buena especificación | Producto pulido que resuelve el problema equivocado |
Los dos no son intercambiables, y ninguno reemplaza al otro. Una verificación fuerte con una validación débil te da un producto sin defectos que nadie quiere. Una validación fuerte con una verificación débil te da la idea correcta implementada en un código inestable. Necesitas ambos, aplicados en el momento adecuado.
Una mnemotécnica simple: la verificación es probar contra el documento, la validación es probar contra el propósito.
Cómo se aplica esto en las pruebas de API
Las API hacen la distinción concreta, porque una API tiene una especificación explícita y legible por máquina: su definición OpenAPI o de esquema. Esa especificación es la línea base de verificación.
La verificación para una API significa verificar la implementación contra ese contrato:
- ¿Cada endpoint devuelve los códigos de estado documentados? Lograr que estos sean consistentes es una disciplina propia; vea qué códigos de estado HTTP deben usar las API REST.
- ¿Cada respuesta coincide con el esquema documentado, con los nombres y tipos de campo correctos?
- ¿Se aplican los parámetros requeridos exactamente como se especifica?
- ¿El formato de error coincide con la forma de error documentada?
Aquí es también donde reside la prueba de contrato de API. Una prueba de contrato es pura verificación: confirma que el productor aún respeta el acuerdo del que dependen los consumidores. Las aserciones de API sobre el estado, el esquema y los encabezados son la unidad de trabajo de verificación.
La validación para una API significa verificar si la API realmente sirve a sus consumidores:
- ¿Puede un cliente completar un flujo de trabajo real de extremo a extremo, iniciar sesión, crear, actualizar, eliminar, sin rodeos incómodos?
- ¿Los datos que devuelve la API realmente responden a las preguntas que hacen los desarrolladores clientes?
- ¿Es el modelo de autenticación práctico para las integraciones existentes?
- ¿Los ejemplos documentados reflejan cómo se usa realmente la API?
Un escenario de prueba de API que encadena varias solicitudes en un viaje completo del usuario está más cerca de la validación; una comprobación de esquema de un solo endpoint es verificación. Ambos pertenecen al conjunto de pruebas. Comprender escenarios de prueba vs. casos de prueba te ayuda a ver en qué capa estás trabajando.
Dónde encaja Apidog
Apidog soporta ambos lados de la distinción porque mantiene el diseño, las pruebas y la documentación de la API en un solo espacio de trabajo.
Para la verificación, el diseño de la API es la especificación. Cuando construyes una prueba, asertas las respuestas contra el mismo esquema que define la API, por lo que la verificación no tiene una segunda copia del contrato para desviarse. Las aserciones de esquema, las aserciones de estado y las comprobaciones de contrato se ejecutan contra la fuente de la verdad. Ejecútalas en cada commit a través de CI; la automatización de pruebas de API en CI/CD hace que la verificación sea continua, que es exactamente cuando debería ocurrir.
Para la validación, los escenarios de prueba de Apidog encadenan múltiples endpoints en flujos de trabajo completos. Puedes construir un escenario que registre un usuario, inicie sesión, cree un recurso y confirme el resultado, y luego ejecutarlo de la misma manera que lo haría un cliente real. Ese ejercicio de extremo a extremo es cómo se verifica que la API resuelve el problema real, no solo que cada endpoint coincide con su línea en la especificación.
Los informes cierran el círculo. Apidog genera resultados por paso, por lo que una comprobación de verificación fallida (una falta de coincidencia de esquema) y una comprobación de validación fallida (un flujo de trabajo multipaso roto) son visibles, distintas y rastreables.
Descargue Apidog para configurar tanto la verificación a nivel de contrato como la validación a nivel de flujo de trabajo contra su propia API.
Un ejemplo del mundo real
Imagine un equipo que construye una API de pagos. La especificación dice que POST /payments acepta una cantidad y una moneda, devuelve 201 con un payment_id y rechaza monedas no válidas con un 400.
La verificación en esta API transcurre sin problemas. La revisión del código confirma que el manejador coincide con el diseño. Las aserciones de esquema confirman que cada respuesta tiene los campos y tipos documentados. Las pruebas de contrato confirman que la forma del error 400 es exactamente la especificada. Las comprobaciones de códigos de estado pasan en todos los ámbitos. Según todas las medidas de verificación, la API está bien construida.
Luego, el primer cliente real se integra. Descubren que la API acepta una cantidad como número de coma flotante, por lo que 0.1 + 0.2 se redondea a un valor que no coincide con la factura del cliente. La especificación decía "cantidad: número". La implementación la respetó perfectamente. La especificación estaba equivocada; el dinero nunca debería ser un flotante. La verificación nunca podría haber detectado esto, porque la verificación solo verifica la implementación contra la especificación, y ambas coincidían.
La validación lo detecta. En el momento en que un cliente ejecuta un pago real de extremo a extremo y lo concilia con una factura, el error de redondeo sale a la superficie. La solución no es un informe de defectos de código; es un cambio de especificación, las cantidades se convierten en unidades menores enteras. Esa es la firma de un hallazgo de validación: la respuesta no es "arreglar el código para que coincida con la especificación", es "la especificación misma estaba equivocada".
Por eso ambos importan. La verificación habría enviado una implementación impecable de un contrato defectuoso. La validación, al ejercitar la API de la manera en que lo hace un consumidor real, es lo único que expone el contrato como el problema.
Una lista de verificación práctica
Para cada lanzamiento de API, ejecute ambas columnas:
Verificación (contra la especificación):
- Cada endpoint devuelve los códigos de estado documentados
- Cada respuesta se ajusta a su esquema
- Los parámetros requeridos se aplican
- Las respuestas de error coinciden con la forma documentada
- Las pruebas de contrato pasan para todos los endpoints orientados al consumidor
Validación (contra el propósito):
- Un nuevo cliente puede completar el flujo de trabajo central de extremo a extremo
- Los datos devueltos responden a las preguntas reales del cliente
- El flujo de autenticación funciona para los patrones de integración reales
- Los ejemplos documentados coinciden con el uso real
- Los interesados confirman que la API resuelve el problema previsto
Si solo pasa la primera columna, tienes una implementación correcta de un diseño posiblemente erróneo. Si solo pasa la segunda, tienes la idea correcta en un código inestable. Entregar con confianza significa tener ambos.
Preguntas frecuentes
¿Se hace primero la verificación o la validación? La verificación comienza primero y se ejecuta continuamente, ya que puedes verificar el código contra una especificación tan pronto como existe el código. La validación llega una vez que hay un producto utilizable para ejercitar contra necesidades reales.
¿La prueba es lo mismo que la validación? No. Las pruebas abarcan ambos. Las pruebas unitarias y las comprobaciones de esquema son verificación; las pruebas de aceptación y de extremo a extremo son validación. El término "prueba" cubre todo el rango.
¿Puede el software pasar la verificación pero fallar la validación? Sí, y es común. La implementación coincide perfectamente con la especificación, pero la especificación resolvió el problema equivocado. Ese producto está verificado pero no validado.
¿Cómo se aplica esto a las pruebas de contrato de API? Las pruebas de contrato son verificación. Confirman que una API sigue respetando su acuerdo documentado con los consumidores. No confirman que ese acuerdo fuera el correcto; ese es el trabajo de la validación.
¿Cuál encuentra más errores? La verificación encuentra más defectos por conteo, ya que se ejecuta continuamente y detecta pequeñas desviaciones temprano. La validación encuentra menos problemas pero más costosos, porque un fallo de validación generalmente significa que un requisito o diseño era incorrecto, no solo el código.
¿Puede la automatización cubrir ambos? La automatización maneja bien la verificación: las comprobaciones de esquema, las pruebas de contrato y las aserciones de estado se ejecutan en cada commit. La validación es más difícil de automatizar por completo porque depende del juicio sobre el ajuste al mundo real, aunque las pruebas de flujo de trabajo de extremo a extremo automatizan una parte significativa de ello.