Module 02 · Mener une campagne · 15 min
Exécuter, et lire les résultats
Les verdicts qu'une exécution peut recevoir, pourquoi un test ignoré ou instable n'est jamais un succès, et un vrai rapport de pipeline lu par le moteur.
Révision
De la leçon précédente : EX-07 ne peut pas être testée dans CAMP-03. Que devient-elle dans les rapports de la campagne ?
La réponse du cours
Elle reste dans chaque rapport, listée comme non testable avec sa raison (pas d'environnement de charge). La supprimer ferait paraître les rapports complets alors qu'une exigence n'a jamais été mesurée.
Six verdicts, pas deux
Une exécution n'est pas seulement « OK » ou « KO ». Chaque verdict dit autre chose, et les confondre, c'est ainsi qu'un rapport finit par affirmer plus que ce qui a été testé.
| Verdict | Signifie | Compte comme |
|---|---|---|
| OK | Chaque pas a donné son résultat attendu | Exécuté, un succès |
| KO | Au moins un pas a différé de son résultat attendu | Exécuté, un échec |
| Bloqué | Le test n'a pas pu aller au bout : données manquantes, environnement arrêté, prérequis absent | Non exécuté |
| Non applicable | Le cas ne s'applique pas à cette version | Exécuté, mis de côté |
| Non testable | La campagne n'a pas les moyens de le tester | Laissé de côté, et listé |
| Arbitré | Il a échoué, et une personne habilitée a accepté l'écart, par écrit | Exécuté, jamais un succès |
Trois règles les accompagnent :
- Un test manuel est passé par une personne, et l'exécution enregistre laquelle. Personne ne déclare réussi un test d'écran à la place de quelqu'un d'autre.
- Un cas exécuté sur plusieurs jeux de données prend le pire résultat. OK sur deux profils et KO sur le troisième, c'est KO.
- Un test instable compte comme un échec tant qu'il n'est pas corrigé. Le relancer jusqu'à ce qu'il passe cache un défaut, dans le produit ou dans le test.
Un rapport du pipeline
Les tests automatisés ne reçoivent pas leur verdict d'une personne : l'outil de test écrit un rapport, en général au format JUnit XML. Le piège est de n'en lire que la dernière ligne.
Voici le rapport du pipeline de ClaimTriage pour le build 2.3.0-142. Le moteur le lit avec le script qu'utilise le Testing Agent, qui le résume par niveau. Regardez le rapport brut si vous le voulez, puis prédisez : quel niveau n'a pas été testé du tout ?
Le rapport de test du pipeline de ClaimTriage
JUnit XML, build 2.3.0-142, tel que l'outil de test l'a écrit. Le moteur le lit avec le script du Testing Agent.
Afficher le rapport brut
…
Faites d'abord votre prédiction.
Ce que dit le résumé
Dix-sept tests, treize réussis : un tableau de bord afficherait 76 % de vert, ou « 1 échec ». Le résumé par niveau dit autre chose :
- Composant : échoué. Un vrai échec d'assertion, le sinistre voyage critique routé vers
queue-travel, le bogue du module 01. Et un test ignoré, avec pour seule raison « flaky, to look at later ». - Intégration : incomplet. Deux tests se sont arrêtés sur
ConnectionRefusedErroravant de vérifier quoi que ce soit : le simulateur du système des sinistres n'était pas lancé. - Système : non testé. Zéro test. Pas « réussi » : non testé. Ni l'authentification unique, ni les droits appliqués par la plateforme, ni aucun parcours de bout en bout n'ont été vérifiés par ce pipeline.
Un niveau sans test est déclaré non testé, jamais réussi. Un test ignoré ou en erreur n'est jamais compté comme réussi.
Chaque problème compte pour autre chose
La leçon suivante prolonge l'exécution en échec : ce qui transforme un KO en anomalie qu'on peut corriger.