Quelle version UCP avez-vous réellement vérifiée ?
Pour rendre un contrôle UCP reproductible, conservez les références exactes des documents, schémas et profils utilisés. La date du protocole seule ne décrit ni les capacités testées ni leur configuration.
Ajoutez ce dossier de version à votre recette d'implémentation UCP, puis rattachez-y chaque exécution.
La même date de version ne suffit pas à retrouver les mêmes fichiers
La politique de versionnement UCP décrit des branches de release maintenues et un processus de backport. Il faut donc distinguer le nom d'une version et la révision exacte des artefacts examinés. Une note de recette qui ne conserve qu'une date peut devenir difficile à reproduire si les références consultées ont évolué.
Pour une validation, rassemblez la référence de protocole, les schémas utilisés, le code de l'intégration et les données de test. Ces objets peuvent avoir des cycles de mise à jour différents. Leur présence dans un même dossier ne prouve pas qu'ils ont été exécutés ensemble ; le reçu de test doit les relier.
| Référence conservée | Ce qu'elle permet de retrouver |
|---|---|
| Version de protocole | Le contrat annoncé pour l'échange |
| Révision de la documentation | Le texte utilisé pour interpréter ce contrat |
| Schémas et empreintes | Les fichiers soumis au validateur |
| Révision de l'intégration | Le code qui a construit et lu les échanges |
| Jeu de cas | Les entrées et résultats attendus |
| Journal d'exécution | Ce qui a effectivement été testé |
L'empreinte d'un fichier prouve que deux copies sont identiques. Elle ne prouve ni la qualité de son contenu ni la conformité d'une intégration. Cette distinction évite d'utiliser un registre d'empreintes comme une certification.
Reproduire un désaccord avec un dossier minimal
Voici un scénario de travail fictif : une équipe accepte une réponse, une autre la rejette. Elles déclarent toutes deux utiliser la même version UCP. Avant de discuter de la conclusion, comparez leurs schémas, la révision de leurs validateurs et la réponse exacte examinée.
Le désaccord peut venir d'un artefact différent, d'une option du validateur ou d'une interprétation métier qui n'est pas couverte par le schéma. Le dossier doit permettre de départager ces hypothèses. « Conforme à la dernière version » ne fournit aucune de ces informations.
Conservez un cas réduit qui reproduit le désaccord, avec des données fictives ou expurgées. Expliquez ce qui a été retiré et pourquoi cela ne change pas le point étudié. Cette réduction aide à discuter d'une règle précise sans exposer un échange marchand complet.
Classer l'effet d'une mise à jour avant de tout relancer
Une modification documentaire, un schéma corrigé et un changement de comportement n'ont pas nécessairement le même effet sur la recette. Comparez les références et identifiez les assertions susceptibles d'être affectées. La décision de rejouer un cas doit être liée à ce changement.
Lorsqu'une équipe conserve un ancien résultat, elle doit pouvoir expliquer pourquoi il reste pertinent. Lorsqu'elle réexécute un test, elle doit conserver la nouvelle sortie plutôt que déplacer simplement la date du reçu précédent.
Pour un transfert à une autre équipe, préparez une courte notice : comment retrouver les artefacts, quelle commande ou procédure a été utilisée et quels cas restent non exécutés. Ce sont ces informations qui rendent le résultat réutilisable après le départ de la personne ayant conduit la recette.
Distinguer les deux participants
Une plateforme et un marchand peuvent annoncer des capacités différentes. Le rapport doit identifier les profils examinés et les éléments effectivement négociés, selon la spécification UCP.
Évitez la formule « toutes les capacités passent » si seuls certains parcours ont été testés. Décrivez les opérations couvertes et celles qui restent hors périmètre.
Si le profil public change pendant la recette, conservez cette observation. Elle peut expliquer pourquoi deux exécutions utilisant le même code obtiennent des résultats différents.
Rattacher les résultats à une exécution
Un fichier de scénario n'est pas une preuve d'exécution. Associez chaque résultat à une date, à la version de l'outil et aux entrées pertinentes. Masquez les données sensibles sans effacer le contexte nécessaire au diagnostic.
Pour un échec, conservez le message utile et l'étape concernée. Pour un succès, décrivez le critère satisfait : validation de schéma, réponse métier attendue ou parcours complet en environnement de test. Ces niveaux ne sont pas équivalents.
