Une équipe peut construire un logiciel qui correspond parfaitement à ses spécifications et livrer quand même le mauvais produit. Elle peut aussi construire exactement le bon produit sur un code criblé de défauts. Ces deux échecs ont des noms : le premier est un problème de vérification, le second est un problème de validation. Confondre les deux explique comment les processus qualité finissent par être actifs mais inefficaces.
Ce guide définit ces deux termes, expose leurs différences et montre où chacun d'eux se situe dans un workflow de test d'API avec Apidog.
Qu'est-ce que la vérification ?
La vérification demande : construisons-nous le produit correctement ?
Elle vérifie qu'un logiciel est conforme à ses spécifications, à sa conception et à ses standards. La vérification compare le travail à l'intention documentée. Elle ne demande pas si cette intention était correcte ; elle demande seulement si l'implémentation y correspond.
La vérification se fait en continu, tout au long du développement, et non à la fin. Les activités de vérification typiques incluent :
- Revues de code et visites guidées (walkthroughs)
- Analyse statique et linting
- Revues de conception et d'architecture
- Vérifications de schémas et de contrats
- Tests unitaires confirmant qu'une fonction fait ce que sa signature promet
La caractéristique clé est que la vérification est principalement interne. Elle compare un artefact à un autre : le code à la conception, la réponse au schéma, l'implémentation à la spécification. Aucun utilisateur réel n'est requis. Si la spécification indique que le point de terminaison renvoie un code 201 avec un en-tête Location, la vérification confirme qu'il fait exactement cela.
Qu'est-ce que la validation ?
La validation demande : construisons-nous le bon produit ?
Elle vérifie que le logiciel répond réellement aux besoins des utilisateurs et résout le vrai problème, indépendamment de ce que la spécification indiquait. La validation compare le travail à la réalité et à l'intention d'utilisation, non à un document.
La validation a tendance à se produire plus tard, une fois qu'il y a quelque chose qu'un utilisateur ou une partie prenante peut exercer. Les activités de validation typiques incluent :
- Tests d'acceptation utilisateur
- Programmes bêta et tests d'utilisabilité
- Tests de bout en bout des flux de travail complets
- Démos et validation par les parties prenantes
La caractéristique clé est que la validation est orientée vers l'extérieur. Elle demande si le produit fini est utile et correct dans son contexte. Une API peut réussir toutes les vérifications, se conformer parfaitement à sa spécification OpenAPI, et échouer quand même à la validation parce que la spécification elle-même a résolu le mauvais problème ; le modèle de pagination est inutilisable, ou le flux d'authentification ne correspond pas à la manière dont les clients s'intègrent réellement.
Validation vs vérification : les différences
| Dimension | Vérification | Validation |
|---|---|---|
| Question centrale | Construisons-nous le produit correctement ? | Construisons-nous le bon produit ? |
| Comparé à | Spécification, conception, standards | Besoins utilisateurs, utilisation réelle |
| Moment | Continue, tout au long du développement | Plus tard, une fois qu'un élément est utilisable |
| Méthodes typiques | Revues, analyse statique, tests unitaires, vérifications de schémas | Tests d'acceptation, bêta, de bout en bout, démos |
| Direction | Interne : artefact vs artefact | Externe : produit vs réalité |
| Détecte | Défauts, écarts par rapport à la spécification, dérive du contrat | Exigences erronées, mauvaise adéquation, lacunes d'utilisabilité |
| Coût de l'omission | Code bogué qui correspond à une bonne spécification | Produit raffiné résolvant le mauvais problème |
Les deux ne sont pas interchangeables, et aucun ne remplace l'autre. Une vérification forte avec une validation faible vous donne un produit sans défaut que personne ne veut. Une validation forte avec une vérification faible vous donne la bonne idée implémentée sur un code instable. Vous avez besoin des deux, appliquées au bon moment.
Un moyen mnémotechnique simple : la vérification est le test par rapport au document, la validation est le test par rapport à l'objectif.
Comment cela se manifeste dans les tests d'API
Les API rendent la distinction concrète, car une API possède une spécification explicite et lisible par machine : sa définition OpenAPI ou son schéma. Cette spécification est la base de référence pour la vérification.
La vérification pour une API signifie vérifier l'implémentation par rapport à ce contrat :
- Chaque point de terminaison renvoie-t-il les codes de statut documentés ? Rendre ces codes cohérents est une discipline en soi ; voir quels codes de statut HTTP les API REST devraient utiliser.
- Chaque réponse correspond-elle au schéma documenté, avec les bons noms de champs et types ?
- Les paramètres requis sont-ils appliqués exactement comme spécifié ?
- Le format d'erreur correspond-il à la forme d'erreur documentée ?
C'est aussi là que se situe le test de contrat d'API. Un test de contrat est une pure vérification : il confirme que le producteur respecte toujours l'accord dont dépendent les consommateurs. Les assertions d'API sur le statut, le schéma et les en-têtes sont l'unité de travail de vérification.
La validation pour une API signifie vérifier si l'API sert véritablement ses consommateurs :
- Un client peut-il compléter un véritable workflow de bout en bout (connexion, création, mise à jour, suppression) sans contournements compliqués ?
- Les données renvoyées par l'API répondent-elles réellement aux questions posées par les développeurs clients ?
- Le modèle d'authentification est-il pratique pour les intégrations existantes ?
- Les exemples documentés reflètent-ils la manière dont l'API est réellement utilisée ?
Un scénario de test d'API qui enchaîne plusieurs requêtes en un parcours utilisateur complet se rapproche de la validation ; une vérification de schéma de point de terminaison unique est une vérification. Les deux font partie de la suite. Comprendre les scénarios de test vs les cas de test vous aide à voir à quelle couche vous travaillez.
Où Apidog s'insère
Apidog prend en charge les deux côtés de la distinction car il maintient la conception, les tests et la documentation des API dans un seul espace de travail.
Pour la vérification, la conception de l'API est la spécification. Lorsque vous créez un test, vous affirmez les réponses par rapport au même schéma qui définit l'API, de sorte que la vérification n'a pas de seconde copie du contrat pour s'en écarter. Les assertions de schéma, les assertions de statut et les vérifications de contrat s'exécutent toutes par rapport à la source de vérité. Exécutez-les à chaque commit via l'intégration continue (CI) ; l'automatisation des tests API en CI/CD rend la vérification continue, ce qui est exactement le moment où elle devrait avoir lieu.
Pour la validation, les scénarios de test Apidog enchaînent plusieurs points de terminaison en des workflows complets. Vous pouvez construire un scénario qui enregistre un utilisateur, se connecte, crée une ressource et confirme le résultat, puis l'exécuter comme le ferait un client réel. Cet exercice de bout en bout est la façon de vérifier que l'API résout le problème réel, et non pas seulement que chaque point de terminaison correspond à sa ligne dans la spécification.
Le reporting boucle la boucle. Apidog génère des résultats par étape, de sorte qu'une vérification échouée (une non-concordance de schéma) et une validation échouée (un workflow multi-étapes cassé) sont toutes deux visibles, distinctes et traçables.
Téléchargez Apidog pour configurer à la fois la vérification au niveau du contrat et la validation au niveau du workflow pour votre propre API.
Un exemple concret
Imaginez une équipe construisant une API de paiements. La spécification dit que POST /payments accepte un montant et une devise, renvoie un code 201 avec un payment_id, et rejette les devises invalides avec un code 400.
La vérification de cette API se déroule sans accroc. La revue de code confirme que le gestionnaire correspond à la conception. Les assertions de schéma confirment que chaque réponse a les champs et types documentés. Les tests de contrat confirment que la forme de l'erreur 400 est exactement telle que spécifiée. Les vérifications de code de statut passent partout. Par toutes les mesures de vérification, l'API est construite correctement.
Puis le premier client réel s'intègre. Il découvre que l'API accepte un montant comme un nombre à virgule flottante, de sorte que 0.1 + 0.2 est arrondi à une valeur qui ne correspond pas à la facture du client. La spécification disait « amount: number ». L'implémentation l'a parfaitement respectée. La spécification était fausse ; l'argent ne devrait jamais être un flottant. La vérification n'aurait jamais pu détecter cela, car la vérification ne vérifie l'implémentation que par rapport à la spécification, et les deux étaient en accord.
La validation le détecte. Au moment où un client effectue un paiement réel de bout en bout et le rapproche d'une facture, l'erreur d'arrondi apparaît. La solution n'est pas un rapport de défaut de code ; c'est un changement de spécification, les montants deviennent des unités mineures entières. C'est la signature d'une découverte de validation : la réponse n'est pas « corriger le code pour correspondre à la spécification », c'est « la spécification elle-même était fausse ».
C'est pourquoi les deux comptent. La vérification aurait livré une implémentation sans faille d'un contrat défectueux. La validation, en exerçant l'API comme le ferait un consommateur réel, est la seule chose qui expose le contrat comme étant le problème.
Une liste de contrôle pratique
Pour toute version d'API, exécutez les deux colonnes :
Vérification (par rapport à la spécification) :
- Chaque point de terminaison renvoie les codes de statut documentés
- Chaque réponse est conforme à son schéma
- Les paramètres requis sont appliqués
- Les réponses d'erreur correspondent à la forme documentée
- Les tests de contrat passent pour tous les points de terminaison orientés consommateur
Validation (par rapport à l'objectif) :
- Un nouveau client peut compléter le workflow principal de bout en bout
- Les données renvoyées répondent aux questions réelles des clients
- Le flux d'authentification fonctionne pour les modèles d'intégration réels
- Les exemples documentés correspondent à l'utilisation réelle
- Les parties prenantes confirment que l'API résout le problème visé
Si seule la première colonne passe, vous avez une implémentation correcte d'une conception potentiellement erronée. Si seule la seconde passe, vous avez la bonne idée sur un code instable. Livrer en toute confiance signifie les deux.
Questions fréquemment posées
La vérification ou la validation est-elle effectuée en premier ? La vérification commence en premier et s'exécute en continu, car vous pouvez vérifier le code par rapport à une spécification dès que le code existe. La validation intervient une fois qu'il existe un produit utilisable pour être exercé par rapport aux besoins réels.
Le test est-il la même chose que la validation ? Non. Le test englobe les deux. Les tests unitaires et les vérifications de schéma sont de la vérification ; les tests d'acceptation et de bout en bout sont de la validation. Le terme « test » couvre toute la gamme.
Un logiciel peut-il passer la vérification mais échouer à la validation ? Oui, et c'est courant. L'implémentation correspond parfaitement à la spécification, mais la spécification a résolu le mauvais problème. Ce produit est vérifié mais non validé.
Comment cela s'applique-t-il aux tests de contrat d'API ? Le test de contrat est une vérification. Il confirme qu'une API respecte toujours son accord documenté avec les consommateurs. Il ne confirme pas que cet accord était le bon ; c'est le travail de la validation.
Lequel trouve le plus de bogues ? La vérification trouve plus de défauts en nombre, car elle s'exécute en continu et détecte les petites déviations tôt. La validation trouve moins de problèmes mais des problèmes plus coûteux, car un échec de validation signifie généralement qu'une exigence ou une conception était erronée, et non seulement le code.
L'automatisation peut-elle couvrir les deux ? L'automatisation gère bien la vérification : les vérifications de schéma, les tests de contrat et les assertions de statut s'exécutent à chaque commit. La validation est plus difficile à automatiser entièrement car elle dépend du jugement sur l'adéquation au monde réel, bien que les tests de workflow de bout en bout en automatisent une partie significative.