Un test qui trouve un défaut n'a servi à rien tant que le défaut n'est pas
arrivé chez quelqu'un qui peut le corriger. C'est la moitié de l'outil.
Le résumé métier
Ce qu'un lecteur non technique doit pouvoir lire en dix secondes.
En fin de run : le parcours — les intitulés effectivement cliqués,
lus sur les éléments eux-mêmes — et le panier, reconstitué depuis les
valeurs captées qui évoquent un prix ou un total. « Sur place → Menu Burger », panier
« 9,40 € ». Pas un sélecteur CSS en vue.
Lisible sans le contexte technique
Le rapport HTML
La preuve, autonome, transmissible.
Un rapport par scénario et un consolidé par set, auto-contenus — images en
base64, donc lisibles par double-clic sans rien d'autre. Durée, vrai titre
d'écran, détail dépliable par pas, et pour chaque vérification reliée au brief : la
phrase métier attendue, la citation verbatim, et l'extrait du brief affiché
côte à côte avec la capture de l'écran réel.
Le rapport porte aussi le numéro de version et la machine qui l'a
produit — et l'heure de compilation gravée dans le binaire, qui ne ment pas, là où une
date de fichier survit mal à une copie.
Auto-contenuJournal JSON à côté
La fenêtre Bugs, et l'hypothèse
Transformer un pas rouge en quelque chose qu'on peut envoyer.
Dès qu'un run a des échecs, une fenêtre s'ouvre : un bug par pas en échec, avec le
cas de test, la station, l'écran, l'attendu, l'obtenu, l'erreur — et une
hypothèse en langage métier sur la cause probable (« l'ordre a
peut-être changé côté borne », « nécessite peut-être un défilement »).
L'hypothèse est une piste, pas un verdict, et le libellé le
dit. Un diagnostic automatique présenté comme une conclusion serait pire que pas de
diagnostic du tout.
Un bug par pas en échec
Jira
Créer le ticket sans quitter le rapport.
Un bouton dans le détail du bug crée le ticket dans le projet QA, avec le rapporteur
choisi dans la liste réelle des comptes assignables, la description complète, et les
pièces jointes — capture d'écran et extrait de brief. Les images sont
réinsérées en ligne dans la description, pas reléguées en bas de
page.
Le bouton parle à l'agent, pas à Jira : c'est l'agent qui détient les identifiants.
Conséquence pratique — l'agent doit tourner pour que le bouton
fonctionne, et il le dit clairement si ce n'est pas le cas. Une pièce jointe qui
échoue n'empêche jamais la création du ticket.
Vérifié sur tickets réels
Xray
Faire remonter un run rouge jusqu'à l'exigence de campagne qu'il met en défaut.
Un scénario devient un Test, une passe de set devient une
Test Execution portant un résultat par scénario. La projection est
automatique en fin de run, sans écran ni bouton.
La couverture remonte par la Story : quand le Test échoue, la Story passe en
NOK toute seule. C'est le point d'arrivée de toute la chaîne — un run rouge
sur la borne rend visible, dans Jira, l'exigence de campagne qui n'est pas tenue.
Deux règles de prudence. La projection ne bloque
jamais : Jira injoignable, le rapport est écrit quand même et l'échec est signalé
à côté — sinon on transforme une recette kiosque en test de connectivité Atlassian.
Et par défaut, seule une passe de set part : un scénario isolé relancé dix fois
dans une soirée de mise au point n'a rien à faire dans l'historique.
Automatique en fin de runEssai à blanc par défaut
Les quatre statuts, et pourquoi il n'y en a pas cinq
L'instance ne connaît que PASSED, FAILED, TO DO, EXECUTING — il n'y a
pas d'ABORTED. Un run empêché par l'environnement — borne injoignable, portproxy tombé —
reste donc à TO DO, jamais FAILED.
C'est la distinction ÉCHEC / NON EXÉCUTÉ tenue jusqu'au bout de la
chaîne. Sans elle, trois matins rouges pour une raison d'environnement suffisent à ce
que plus personne ne lise les rapports.