Faut-il capturer chaque étape d'un test QA ?

Un enregistrement QA a deux lecteurs : le relecteur qui valide le test aujourd'hui et la personne qui analysera une régression dans quelques mois. Les deux doivent voir ce qui a été testé, avec quelles données et ce qui s'est passé. Aucun ne doit voir une capture de chaque clic.

Cet article explique comment structurer un enregistrement de test manuel et dans quels cas les captures d'écran apportent une preuve, avec le flux de travail Temposhot sur Mac.

Les exemples utilisent un seul cas de test tout au long de l'article : TC-142, une réinitialisation de mot de passe sur un site de préproduction. Le test comporte 4 étapes. Un enregistrement par points de contrôle de ce test contient 5 pages. Enregistrer chaque clic du même test produit 11 pages.

Définir un objectif de test unique

Chaque cas de test doit vérifier un seul comportement. « L'utilisateur peut réinitialiser son mot de passe avec un lien valide envoyé par e-mail » est un objectif unique. « Les paramètres du compte fonctionnent » relève d'un plan de test, pas d'un cas de test.

Formulez l'objectif sous la forme d'une phrase qui peut être vraie ou fausse. La capture finale montre laquelle.

Séparer les objectifs qui cachent deux tests

Un objectif contenant « et » cache souvent deux tests. « L'utilisateur peut réinitialiser son mot de passe et modifier son adresse e-mail » échoue dans son ensemble lorsqu'une seule partie casse, et l'enregistrement n'indique pas laquelle. Séparez-le en deux cas, chacun avec son identifiant et son enregistrement.

Un objectif étroit garde aussi l'enregistrement court. TC-142 se termine lorsque l'utilisateur est connecté avec le nouveau mot de passe. La vérification que l'ancien mot de passe ne fonctionne plus fait l'objet d'un cas distinct, TC-143, avec son propre état de départ.

Écrire l'objectif du point de vue de l'utilisateur

Un objectif écrit du point de vue de l'utilisateur désigne un résultat visible par celui-ci. « L'utilisateur peut réinitialiser son mot de passe avec un lien valide envoyé par e-mail » se termine sur un écran : le tableau de bord après la connexion. Un objectif tel que « L'endpoint de réinitialisation renvoie 200 » se termine dans un journal, et un enregistrement de captures d'écran n'est pas le bon format pour le vérifier.

Lorsqu'un cas combine les deux, conservez le résultat visible comme objectif et joignez les lignes de journal en texte. Les captures d'écran prouvent alors le résultat pour l'utilisateur, et le texte prouve le comportement du système qui le produit.

Enregistrer les prérequis et les données de test

Listez ce qui doit exister avant la première étape, afin que n'importe qui puisse rejouer le test :

Élément	Exemple
Identifiant du cas de test	TC-142
Build ou version	Le numéro de build testé
Environnement	URL de préproduction, version de macOS, navigateur et sa version
Compte	Rôle et nom du compte de test, jamais un vrai client
Données de test	La commande, le fichier ou l'enregistrement utilisé par le test
Préconditions	Indicateur de fonctionnalité activé, panier vide, utilisateur déconnecté

Utilisez des données synthétiques. Les enregistrements de test sont largement partagés et conservés longtemps.

Vérifier les préconditions sur la première page

Une précondition qui n'est que notée ne peut pas être vérifiée plus tard. La première page de l'enregistrement doit montrer l'état de départ à l'écran, par exemple la page de connexion en état déconnecté avec l'URL de préproduction visible. Le relecteur peut alors confirmer l'environnement sans poser de question.

Une boîte de réception de test vide est essentielle pour TC-142. Si un ancien e-mail de réinitialisation s'y trouve, le testeur peut ouvrir le mauvais lien, et l'enregistrement affiche un succès pour un lien qui n'était pas testé.

Utiliser des données de test manifestement fictives

Les données synthétiques doivent paraître fictives au premier coup d'œil. Des noms tels que « QA Reset 01 » et des adresses sur un domaine de test indiquent clairement à tout lecteur ultérieur qu'aucune personne réelle n'est concernée. Des noms fictifs mais réalistes, comme un prénom et un nom plausibles, font naître des questions sur la présence de données clients dans l'enregistrement.

Des données de test évidentes réduisent aussi le travail de masquage. Un enregistrement sans donnée personnelle n'a pas besoin de Blur, donc le plan gratuit suffit, et les pages montrent l'écran complet sans zones couvertes.

Rédiger les étapes avec des points de contrôle attendus

Chaque étape comporte une action et, lorsqu'un élément observable doit apparaître, un résultat attendu.

1. Ouvrez la page de connexion. Attendu : le lien « Forgot password » est visible.
2. Sélectionnez Forgot password et saisissez l'e-mail de test. Attendu : message de confirmation.
3. Ouvrez le lien de réinitialisation depuis la boîte de réception de test. Attendu : formulaire de nouveau mot de passe.
4. Saisissez un nouveau mot de passe valide et validez. Attendu : connexion effectuée, tableau de bord affiché.

Les étapes sans résultat attendu relèvent de la préparation. Les étapes avec un résultat attendu sont des points de contrôle, et les captures d'écran doivent être associées aux points de contrôle.

Rendre chaque résultat attendu observable

« Fonctionne correctement » n'est pas un résultat attendu, car aucune capture d'écran ne peut le montrer. Un résultat attendu désigne un élément visible : un texte de message, un champ, une valeur, un titre de page. « Message de confirmation : Check your email for a reset link » peut être comparé mot pour mot avec l'écran.

Si un résultat attendu ne peut pas être vu à l'écran, par exemple un délai de livraison d'e-mail, notez-le sous forme de texte dans la description de la page. La capture montre alors l'écran, et la description porte la valeur.

Conserver des numéros d'étape stables

Les numéros d'étape du cas de test et les titres de page de l'enregistrement doivent correspondre. Si le cas est modifié ultérieurement et qu'une étape est insérée, donnez à la nouvelle étape un suffixe comme 2a au lieu de renuméroter. Les anciens enregistrements pointent alors toujours vers les bonnes étapes, et une recherche de régression sur « étape 4 » retrouve la même action dans chaque build.

Les titres se modifient dans le Page Inspector, sous Page title. Réécrivez chaque titre provisoire pour qu'il commence par l'identifiant du cas et de l'étape, puis ajoutez les lignes Expected et Actual sous Description.

Séparer les étapes de préparation des points de contrôle

TC-142 comporte une préparation que l'enregistrement ne montre pas : ouvrir la boîte de réception de test, copier l'adresse e-mail, attendre l'e-mail. Ne pas les inclure maintient l'enregistrement à 5 pages. Si une action de préparation échoue, elle devient un résultat Blocked avec sa propre page, et non un écart silencieux.

Un test pratique : si une étape n'a pas de ligne « Expected » dans le cas, elle ne reçoit pas de page. Si elle en a une, elle reçoit exactement une page.

Faut-il capturer chaque étape d'un test QA ?

Non. Capturez ces moments :

• État de départ : prouve que les préconditions étaient remplies.
• Chaque point de contrôle : montre le résultat attendu ou inattendu.
• Résultat final : montre si l'objectif a été atteint.
• Tout échec : l'écran au moment de la divergence, ainsi que l'étape qui le précède.

Les captures des simples clics de navigation ajoutent des pages sans ajouter de preuve. Elles rendent l'enregistrement plus lent à relire.

Avec Temposhot, vous pouvez ne capturer que les points de contrôle. Ouvrez Action Capture (Command+3), sélectionnez Configure, puis réglez Mouse click capture pour ne capturer que les clics avec une touche de modification, ou pour ne jamais capturer les clics. Appuyez ensuite sur Shift+Command+2 (le raccourci de capture manuelle) à chaque point de contrôle. Sélectionnez Start Action Capture, choisissez Specific Window, exécutez le test et sélectionnez Finish capture. Le Document s'ouvre avec une page par point de contrôle.

Si vous voulez toutes les étapes d'un test en échec, remettez Mouse click capture sur chaque clic. Chaque clic accepté enregistre la fenêtre juste avant le clic. Le guide Action Capture présente les modes de capture.

Comparer les deux modes d'enregistrement

Les deux modes répondent à des questions différentes. Un enregistrement par points de contrôle répond à la question « chaque point de contrôle a-t-il montré le résultat attendu ». Un enregistrement de chaque clic répond à la question « qu'a fait exactement le testeur », ce qui compte surtout lorsqu'un test échoue.

Le plan gratuit limite une exécution Action Capture à 5 étapes. Un enregistrement TC-142 par points de contrôle tient exactement dans une exécution gratuite : l'état de départ plus 4 points de contrôle. Une exécution avec chaque clic se met en pause après 5 étapes et conserve ces étapes. Temposhot Pro supprime cette limite.

Configurer une exécution par points de contrôle

Configure Action Capture enregistre ses réglages sur le Mac. La configuration par points de contrôle reste donc en place pour la session de test suivante. Rétablissez-la avant d'enregistrer un tutoriel ou un rapport de bug.

Mark clicked area s'applique aussi aux étapes ajoutées avec le raccourci manuel. Dans un enregistrement par points de contrôle, le repère indique l'endroit où le pointeur se trouvait par hasard, ce qui peut induire le relecteur en erreur. Il reste donc désactivé.

Exécuter TC-142 avec le raccourci

1. Capturer l'état de départ

   Après le compte à rebours, appuyez sur Shift+Command+2 sur la page de connexion déconnecté. Il s'agit de la page 1.

2. Capturer chaque point de contrôle

   Exécutez chaque étape. Lorsque le résultat attendu doit être affiché à l'écran, appuyez de nouveau sur le raccourci. Les pages 2 à 5 correspondent aux 4 points de contrôle.

3. Terminer

   Appuyez sur Command+. ou sélectionnez Finish capture. Le Document s'ouvre avec 5 pages.

Points de contrôle qui disparaissent rapidement

Certains résultats attendus ne restent visibles que quelques secondes, comme un message temporaire après l'envoi d'un formulaire. Appuyez sur le raccourci dès que le message apparaît : l'étape enregistre l'écran à cet instant. Si le message a disparu avant l'appui, répétez l'étape et gardez les doigts sur les touches.

Si un résultat apparaît trop brièvement pour être capturé, écrivez-le dans la description et capturez l'écran qui suit. « Expected : message temporaire Password updated. Actual : message aperçu, fermé après environ 3 secondes, tableau de bord affiché. » Le relecteur sait alors que le message a été observé et pourquoi il ne figure pas sur la page.

Tests qui traversent plusieurs fenêtres

TC-142 passe du navigateur à la boîte de réception de test, puis revient au navigateur. Lorsque la boîte de réception s'ouvre dans une autre fenêtre de navigateur, une cible Specific Window continue de ne capturer que la première fenêtre. Pour un test qui utilise plusieurs fenêtres, choisissez Full Screen et fermez tout ce qui n'appartient pas au test avant l'exécution.

Changer de mode lorsqu'un point de contrôle échoue

Lorsque l'étape 4 échoue, un enregistrement par points de contrôle montre le résultat mais pas la saisie exacte. Rejouez le test en mode chaque clic pour enregistrer le chemin menant à l'échec. Joignez cette seconde exécution au rapport de bug, et conservez le premier enregistrement comme résultat du test.

Enregistrer les résultats réels sans réécrire l'historique

L'enregistrement doit montrer ce qui s'est passé, et non ce qui aurait dû se passer. Dans l'éditeur de Document :

• Titrez chaque page avec l'identifiant de l'étape et l'action, par exemple « TC-142 step 4 : Submit new password ».
• Dans la Page description, écrivez les résultats attendus et réels sur des lignes séparées.
• Sur un point de contrôle en échec, dessinez un Rectangle (R) autour de la mauvaise valeur et ajoutez une étiquette Text (T) avec « Fail ».

Ne rognez pas le contexte dont le relecteur a besoin, comme l'URL ou le libellé du build. Utilisez Framing uniquement pour retirer les fenêtres sans rapport. Masquez les données personnelles avec Blur (B, Pro), et ne modifiez jamais une valeur pour donner l'apparence d'un résultat correct.

Règles d'annotation pour les preuves

Les annotations dans Temposhot sont non destructives : la capture sous un rectangle ou une étiquette reste inchangée. Cela préserve la preuve, mais le lecteur du PDF exporté ne voit que la page rendue. Des règles sur ce qu'une annotation peut ou ne peut pas faire garantissent la fiabilité de l'export.

Rédiger la description selon un format fixe

Un format fixe de deux lignes rend les descriptions faciles à parcourir sur 5 ou 50 pages. La première ligne commence par « Expected : » et donne le résultat attendu. La deuxième commence par « Actual : » et décrit ce que montre la capture.

Pour la page 5 de TC-142, la description est : « Expected : signed in, dashboard shown. Actual : banner Reset link expired, sign-in form shown. » Le relecteur peut vérifier la ligne Actual par rapport à la capture d'un seul coup d'œil.

Utiliser ce modèle d'enregistrement d'exécution QA

• Identifiant du cas de test, objectif, build, environnement, testeur, date.
• Préconditions et données de test.
• Étapes avec résultats attendus.
• Captures de l'état de départ, des points de contrôle, de la fin et des échecs.
• Résultat réel par point de contrôle.
• Statut : Pass, Fail ou Blocked.
• Rapport de bug lié pour chaque échec.

Exportez le Document avec Export PDF pour le joindre à l'outil de gestion des tests, ou exportez les pages en PNG depuis More export formats pour des preuves intégrées. Nommez les fichiers avec l'identifiant du cas et le build, par exemple TC-142_build-2026-08-27.pdf. Le guide d'export présente les formats. Pour comparer deux captures du même écran entre plusieurs builds, l'outil du navigateur Compare Images met en évidence les différences en local.

Paramètres PDF pour un enregistrement de test

Les réglages par défaut de Export PDF conviennent à la plupart des enregistrements : A4, Landscape, page de couverture, numéros d'étape et numéros de page activés, descriptions placées avant l'image. La page de couverture affiche le titre du document et le nombre d'étapes. Un titre tel que « TC-142 build 2026-08-27 Fail » place donc le résultat sur la première page. La personnalisation des paramètres PDF nécessite Temposhot Pro.

Avec Pro, les équipes qui impriment sur du papier américain passent Paper size à Letter. Régler Image quality sur Small file maintient un enregistrement de régression de 50 pages assez petit pour les outils qui limitent la taille des pièces jointes.

Définir le statut à partir des preuves

Chaque statut exige des preuves différentes. Un relecteur qui voit un statut sans les pages correspondantes doit renvoyer l'enregistrement.

Organiser les enregistrements par cas et par build

On retrouve un enregistrement plus tard par identifiant de cas et par build, rarement par date seule. Gardez un dossier par cas, avec un sous-dossier par build, afin qu'une recherche de régression compare le même cas d'un build à l'autre.

Les fichiers image de Document portent le nom de leurs titres de page. Des titres commençant par l'identifiant de l'étape donnent donc des fichiers triés dans l'ordre des étapes et identiques d'un build à l'autre.

Comparer un point de contrôle entre plusieurs builds

Lorsque TC-142 réussit sur le build du 2026-09-03 après avoir échoué le 2026-08-27, ouvrez les deux fichiers PNG de l'étape 4 dans Compare Images. La vue à curseur ou la vue de différence de pixels indique si seule la bannière a changé ou si la mise en page a aussi bougé. Conservez les deux enregistrements : l'enregistrement en échec documente la régression.

Vérifier les preuves et valider

Un relecteur doit confirmer trois points sans exécuter le test : les préconditions étaient remplies, chaque point de contrôle montre le résultat indiqué, et le statut final correspond aux captures. Si le relecteur doit deviner, l'enregistrement a besoin d'un point de contrôle supplémentaire.

Temposhot stocke les Documents localement et ne fournit pas de workflow de validation. Joignez les fichiers exportés à l'outil de gestion des tests ou au ticket où les approbations sont suivies.

La revue du relecteur, étape par étape

Un relecteur peut contrôler un enregistrement de 5 pages en quelques minutes en le lisant dans un ordre fixe. D'abord, comparez le titre de couverture et la page 1 avec les préconditions : build, URL et état déconnecté. Ensuite, lisez chaque page de point de contrôle et comparez la ligne « Actual » avec la capture.

Troisièmement, vérifiez que le statut indiqué sur la couverture correspond aux pages. Un enregistrement marqué Pass avec une bannière d'erreur rouge sur la page 5 retourne au testeur. Un enregistrement marqué Fail sans rapport de bug lié retourne également au testeur.

Blocked n'est pas Fail

Un test est Blocked lorsqu'il ne peut pas atteindre un point de contrôle pour une raison extérieure au comportement testé. Dans TC-142, une panne de la préproduction qui empêche l'arrivée de l'e-mail de réinitialisation bloque l'étape 3. L'enregistrement montre l'état de départ et le dernier écran atteignable, avec la raison dans la description.

Marquer un test bloqué comme Fail augmente artificiellement le taux d'échec et envoie un bug à la mauvaise équipe. Le marquer comme Pass masque l'écart. Conservez Blocked comme statut distinct et relancez le cas lorsque le blocage est levé.

Du point de contrôle en échec au nouveau test

Un échec suit un chemin fixe. L'enregistrement d'origine reste inchangé à chaque étape.

Parcours clavier pour une session de test

Un testeur qui exécute 10 ou 20 cas dans une même session gagne à rester au clavier. Les touches ci-dessous couvrent l'enregistrement et la première passe de modification.

Conservation des enregistrements sur le Mac

Les Documents restent sur le Mac qui les a enregistrés, et les sessions brutes restent dans Capture History jusqu'à la limite de conservation. La limite par défaut est de 30 sessions, réglable de 1 à 500 dans Settings > History. Un cycle de test chargé peut dépasser 30 sessions en quelques jours. Exportez donc chaque enregistrement vers l'outil de gestion des tests dès que le cas est terminé.

Questions fréquentes

Les captures d'écran suffisent-elles comme preuve de test ?

Pour les tests d'interface manuels, elles constituent un élément central. Ajoutez les journaux, la sortie de console ou les données réseau sous forme de texte lorsque l'échec n'est pas visible à l'écran. Voir preuve par capture d'écran.

Les tests automatisés doivent-ils aussi produire des captures d'écran ?

Les suites automatisées capturent généralement des captures d'écran en cas d'échec. Pour comparer automatiquement des captures entre plusieurs builds, voir test de régression visuelle.

Comment signaler un échec trouvé pendant la QA ?

Rédigez un rapport de bug distinct, lié au cas de test. Voir comment documenter un bug avec des captures d'écran pas à pas.

Combien de pages un enregistrement de test doit-il contenir ?

Une page pour l'état de départ, une page par point de contrôle et une page pour chaque échec. TC-142 comporte 4 points de contrôle, donc un enregistrement réussi compte 5 pages.

Une page de point de contrôle peut-elle montrer le pointeur ?

Oui. Activez Show cursor in shortcut captures dans Configure Action Capture. Laissez-le désactivé lorsque la position du pointeur n'a aucune signification pour le résultat.

Transformez vos clics en guide pas à pas clair

Action Capture enregistre les points de contrôle sur raccourci ou chaque clic, selon l'exécution. Téléchargez Temposhot et joignez votre prochain enregistrement de test sous forme de PDF ordonné.