Tests manuels ou tests automatisés : pourquoi les tests manuels ne suffisent pas pour les tests de bout en bout
Tests manuels ou automatisés : où les vérifications de bout en bout à la main ne suffisent plus, ce qui reste humain, et comment la QA automatise un cas de test sans code.
Un test manuel, c'est une personne qui vérifie une application à la main ; un test automatisé la rejoue sans personne.Pour les vérifications fonctionnelles et de bout en bout répétées à chaque version, le test manuel ne suffit pas : il est lent, varie d'un testeur à l'autre et ne peut pas tourner à chaque build.
Cet article n'est pas contre les testeurs manuels.Les meilleurs testeurs trouvent des bogues qu'aucun script ne chercherait.Le problème, c'est l'autre partie du travail : parcourir les mêmes formulaires, les mêmes menus et la même commande, version après version, dans chaque navigateur et chaque langue.Cette partie ne passe pas à l'échelle, et elle n'a jamais été un bon usage de l'attention d'un testeur.
Tests manuels et tests automatisés : la différence
Définition
Un test manuel, c'est une personne qui exécute les étapes d'un test et décide à l'œil si l'application se comporte comme il faut.
- Un test automatisé est un test qui rejoue ces étapes tout seul et vérifie le résultat, de la même façon à chaque fois.
- Un test fonctionnel vérifie qu'une fonctionnalité fait ce qu'elle doit, et un test de bout en bout vérifie un parcours entier à travers l'interface, comme un utilisateur le parcourt.
Les deux peuvent se faire à la main ou être automatisés, et la bonne réponse dépend de la fréquence à laquelle la vérification se répète.
Si les tests de régression sont nouveaux pour vous, qu'est-ce que le test de régression explique pourquoi les mêmes vérifications reviennent après chaque changement.
Ce que les tests manuels font encore le mieux
Une comparaison honnête commence par ce que les personnes font mieux que n'importe quel test, et cette liste est bien réelle.
Certains tests ont besoin d'une personne, et en auront toujours besoin.
Le test exploratoire trouve ce que personne n'a pensé à écrire, parce qu'un testeur curieux essaie ce qu'un utilisateur pourrait essayer.
Les revues d'utilisabilité et de design jugent si un écran est clair, ce qu'aucune vérification ne peut décider seule.
Le jugement décide de ce qui compte : quel bogue bloque la version, et lequel peut attendre.
DORA, le programme de recherche derrière les rapports State of DevOps, dit la même chose.Sa page sur l'automatisation des tests recommande de garder des activités manuelles comme le test exploratoire et le test d'utilisabilité, et dit que les testeurs et les équipes QA continuent d'avoir un rôle important.
L'automatisation ne remplace pas les testeurs.Elle leur enlève les vérifications répétées, pour qu'ils fassent les tests que seule une personne peut faire.
Les limites des tests manuels pour les tests de bout en bout
Le test manuel fonctionne bien pour une vérification que l'on fait une fois.Voici les inconvénients qui apparaissent quand les mêmes vérifications fonctionnelles et de bout en bout reviennent à chaque version.
Il ne suit ni le rythme des versions, ni le code écrit par l'IA
Un passage de régression manuel est aussi long que la liste des scénarios, et la liste ne fait que grandir.Chaque fonctionnalité ajoute des vérifications, et presque aucune n'est jamais retirée.
Les assistants de code IA creusent l'écart.Dans son rapport 2026, Faros AI a constaté que la part du code généré par IA acceptée par les développeurs est passée de 20 % à 60 %, et que chaque développeur fusionne 16,2 % de pull requests en plus, en comparant une adoption faible et forte de l'IA chez 22 000 développeurs.Plus de changements arrivent chaque semaine chez les testeurs, alors qu'une personne vérifie toujours à la même vitesse.
Comment tester du code généré par l'IA examine ce problème en détail.
La répétition fait rater des choses
On voit ce que l'on cherche.Au vingtième passage sur le même formulaire, un testeur vérifie le champ que nomme le cas de test et rate le logo qui a disparu juste à côté.
Les experts ne font pas exception.Dans une étude de 2013 publiée dans Psychological Science, des chercheurs ont demandé à 24 radiologues de chercher des nodules pulmonaires sur des scanners, et ont placé dans le dernier un gorille 48 fois plus grand qu'un nodule.83 % d'entre eux ne l'ont pas vu, et le suivi du regard a montré que la plupart de ceux-là l'avaient regardé en face.
L'inspection attentive a aussi un plafond.Dans une étude portant sur 82 inspecteurs formés, publiée dans Human Factors en 2015, ils ont repéré 85 % des pièces défectueuses, proche de la moyenne de 80 % que les auteurs donnent pour l'industrie.Environ un défaut sur sept est passé, chez des personnes dont le métier était de le trouver.
Chaque navigateur, appareil et langue multiplie le travail
Une application web vérifiée dans Chrome n'est pas vérifiée dans Firefox.Un écran vérifié en anglais n'est pas vérifié en allemand, où chaque libellé est plus long.À la main, chaque navigateur, chaque taille d'écran et chaque langue est un passage complet de plus, si bien qu'une équipe multiplie ses heures ou ne vérifie discrètement qu'une seule combinaison.
Les tests multi-navigateurs à partir d'un seul enregistrement montre comment un test web devient une version pour chaque navigateur, appareil et langue.
Il ne peut pas tourner à chaque build
Un développeur peut lancer dix builds par jour ; un testeur ne peut pas vérifier dix fois par jour.Les vérifications manuelles ont donc lieu en fin de sprint, et un bogue trouvé le jeudi a été écrit le lundi.La page de DORA sur l'automatisation des tests le dit clairement : le test de régression manuel prend du temps à exécuter et coûte cher, ce qui en fait un goulot d'étranglement, et les développeurs ne peuvent pas obtenir de retour rapide.
Il laisse peu de preuves
À la fin d'un passage manuel, la trace est une liste de coches, et parfois une capture d'écran d'un échec.Personne ne peut voir après coup à quoi ressemblait l'écran aux étapes réussies, ni comparer cette version avec la précédente.Quand un rapport de bogue dit « ça marchait hier », rien ne permet de le prouver ni dans un sens ni dans l'autre.
Il varie d'un testeur à l'autre
Un cas de test dit « vérifier le récapitulatif de commande ».Un testeur lit le total, un autre lit chaque ligne, un troisième vérifie aussi la date.Chacun a raison, et chaque passage vérifie quelque chose de différent.Le même testeur un vendredi après-midi n'est pas non plus le même testeur un lundi matin.
Son coût grandit à chaque version
Une vérification manuelle coûte les mêmes heures à chaque exécution, pour toujours.Un test automatisé coûte du temps une fois pour le créer et un peu d'entretien quand l'application change volontairement, puis il tourne pour le seul prix du temps machine.Plus un produit vit longtemps, plus l'écart se creuse.
Pourquoi les tests de régression manuels prennent trop de temps
La multiplication est facile à sous-estimer, alors la voici avec des chiffres ronds.Prenons une application web modeste avec 40 scénarios à vérifier avant une version, à environ dix minutes chacun à la main.
| Ce qui est vérifié à la main | Temps par version |
|---|---|
| 40 scénarios, un navigateur, une langue | Environ 6 heures et 40 minutes |
| La même chose, dans Chrome, Edge et Firefox | Environ 20 heures |
| La même chose, en deux langues | Environ 40 heures : une semaine entière d'un testeur |
| Avec une version chaque semaine | Un testeur qui ne fait rien d'autre |
Ces chiffres sont une illustration, pas une enquête : vos scénarios peuvent prendre cinq minutes ou trente.C'est la forme qui compte.Chaque navigateur, chaque langue et chaque version multiplie les heures, alors que le nombre de testeurs reste le même.
À la main, à chaque version
Version 1
Version 2
Version 3
Six passages de dix minutes : une heure pour un seul scénario, à chaque version.
Automatisé, à chaque build
Checkout.GTS
Enregistré une fois, exécuté dans chaque navigateur et chaque langue choisis
- Build 412
- Build 413
- Build 414La casse est détectée le jour même où elle arrive
- Build 415
Personne au clavier, et un rapport pour chaque exécution.
Voilà pourquoi le test de régression manuel devient le goulot d'étranglement d'une version.L'équipe attend le passage, ou livre sans l'avoir terminé.
Tests manuels ou automatisés, tâche par tâche
La réponse honnête n'est pas « tout automatiser ».Chaque type de tâche a sa meilleure façon de se faire.
| Tâche | À la main | Avec un test automatisé |
|---|---|---|
| Explorer une nouvelle fonctionnalité | Mieux : une personne essaie ce que personne n'a prévu | Ne vérifie que ce qui a été décrit |
| Juger l'utilisabilité et le design | Mieux : il faut un jugement humain | Confirme ce qui a été décidé, pas si c'est bien |
| Une vérification ponctuelle d'un correctif | Très bien : elle ne sera pas répétée | Utile seulement si le bogue peut revenir |
| Le même parcours à chaque version | Plus lent à chaque version, et l'attention baisse | Mieux : les mêmes étapes et vérifications à chaque fois |
| Chaque navigateur, appareil et langue | Un passage complet de plus pour chacun | Mieux : un seul test, une exécution pour chacun |
| Le retour après un changement | Des jours plus tard, en fin de sprint | Mieux : quelques minutes après le build |
| Les preuves de ce qui s'est passé | Des coches et une capture d'écran de temps en temps | Mieux : des images, une vidéo et un historique des exécutions |
| Le même résultat, qui que ce soit | Dépend du testeur et du jour | Mieux : identique à chaque exécution |
Quand automatiser les tests, et quand les garder manuels
Automatisez un test quand il sera exécuté à nouveau.
- Un parcours que votre équipe vérifie avant chaque version, comme la connexion, la recherche ou le paiement, est le premier candidat.
- Une vérification répétée dans plusieurs navigateurs, tailles d'écran ou langues vient ensuite, car chaque combinaison multiplie le travail.
- Un bogue qui a déjà atteint les utilisateurs mérite un test, pour qu'il ne revienne jamais sans qu'on le voie.
- Un test de fumée des écrans principaux a sa place à chaque build.
Gardez une vérification manuelle quand elle a besoin d'une personne.
- Une fonctionnalité qui change encore tous les jours coûte moins cher à vérifier à la main jusqu'à ce qu'elle se stabilise.
- Une revue d'utilisabilité ou de design a besoin d'yeux humains.
- Une vérification que vous ne ferez qu'une fois ne vaut pas un test.
Pourquoi les équipes QA n'ont pas automatisé plus tôt
Si l'automatisation est meilleure pour les vérifications répétées, pourquoi tant d'équipes les font-elles encore à la main ?Surtout à cause de ce que l'automatisation a voulu dire jusqu'ici : du code.
Dans les frameworks à coder comme Playwright, Selenium, Cypress, Appium ou WinAppDriver, un test est un programme.Quelqu'un l'écrit dans un langage de programmation, trouve chaque élément avec un sélecteur, et corrige ces sélecteurs quand la page change : la documentation de Playwright elle-même prévient que les sélecteurs CSS et XPath peuvent casser quand la structure de la page change.
| Ce qu'il faut | Un framework à coder | GUI Test Studio |
|---|---|---|
| Qui crée le test | Une personne qui écrit du code | Le testeur qui connaît le scénario |
| Comment il est créé | Un script, écrit ligne par ligne | Un enregistrement du scénario, ou une consigne |
| Ce que vous tenez à jour | Les sélecteurs, les attentes et le code autour | Rien à tenir à jour, tant que l'application ne change pas volontairement |
| Une vérification de l'aspect de l'écran | Du code en plus ou un autre outil | Fait partie de chaque test |
Le cas de test manuel est donc resté manuel : la personne qui le connaissait le mieux ne pouvait pas l'automatiser, et celle qui le pouvait était occupée ailleurs.Quand des suites ont été écrites malgré tout, l'entretien et les résultats instables les ont souvent usées, comme l'explique tests instables et faux positifs.
Comment transformer un cas de test manuel en test automatisé
GUI Test Studio, qui automatise les tests de bout en bout sur Windows, a été conçu pour la personne qui connaît déjà le scénario.Vous faites le test une fois, comme vous le faites à la main aujourd'hui, et il devient un test qui s'exécute tout seul.Il fonctionne avec les applications de bureau, les applications web, les jeux et les téléphones Android.
Enregistrer
Ou le décrire dans une consigne
Vérifier
Choisir ce qu'il vérifie
Exécuter
À chaque build
Lire
Images, vidéo, verdict
- 1
Choisissez un cas de test que vous répétez à chaque version
Commencez par un parcours que votre équipe vérifie à la main avant chaque version, comme la connexion, la recherche ou la passation d'une commande.Plus il est répété souvent, plus vite le test automatisé est rentable.
- 2
Notez son point de départ
Un test rejoue exactement ce que vous avez fait, exactement depuis l'endroit où vous avez commencé.Notez l'écran, le compte et les données dont part le scénario, et remettez l'application là avant chaque exécution.
- 3
Enregistrez-le une fois, ou décrivez-le dans une consigne
Cliquez sur Enregistrer dans GUI Test Runner-Recorder et faites le scénario vous-même, à un rythme normal.Ou collez les étapes du cas de test manuel dans une consigne, et votre assistant IA les exécute avec GUI Test Studio et enregistre le test.
- 4
Choisissez ce qu'il vérifie
Quand l'enregistrement s'arrête, l'application demande ce que ce test doit vérifier : les éléments visuels, le texte et ce qui apparaît à l'écran.Les vérifications sont créées à l'enregistrement du test, une pour chaque élément que vous avez utilisé.
- 5
Exécutez-le une fois, puis peaufinez-le
Remettez l'application là où le test commence et cliquez sur Exécuter le test.Ouvrez-le ensuite dans GUI Test Studio pour nommer les étapes importantes, ajouter une vérification que l'enregistrement n'a pas faite, ou ajuster une attente.
- 6
Exécutez-le à chaque build
Ajoutez gtr-cli, l'exécuteur en ligne de commande, à votre pipeline.Il exécute le test comme le bouton Exécuter le test et donne à votre outil de CI un code de sortie et un fichier JUnit.
- 7
Lisez le rapport quand il échoue
Chaque exécution écrit un rapport de confiance : le verdict, chaque étape, et pour chaque vérification échouée l'image attendue à côté de ce qui a été trouvé, avec la vidéo de l'exécution.
L'enregistrement : le cas de test manuel, fait une fois
Un enregistrement, c'est le passage manuel, fait une dernière fois.Cliquez sur Enregistrer, choisissez l'écran, une application, une application web, une zone ou un téléphone, et faites le scénario comme un utilisateur.Appuyez sur la touche d'arrêt quand vous avez fini.Enregistrer un test montre chaque étape, et votre premier test fait parcourir une page d'entraînement en quelques minutes.
Une consigne : le cas de test, écrit comme vous l'écrivez déjà
Si vos cas de test sont déjà écrits, une consigne peut être plus rapide.Collez les étapes dans la fenêtre Créer ou modifier un test avec une consigne et envoyez-les à votre assistant IA : Claude, ChatGPT avec Codex, ou un modèle d'IA local, l'un des nôtres ou le vôtre.L'assistant exécute les étapes avec GUI Test Studio, vérifie ce que vous avez demandé et enregistre le test.Voir créer un test à partir d'une consigne.
Ouvrir la boutique, chercher « lampe de bureau », ajouter le premier résultat au panier et vérifier que le panier affiche un article au bon prix.Collé tel quel, c'est une consigne.L'assistant fait les étapes, ajoute une vérification du panier et enregistre le test.
Choisir ce qu'il vérifie
Un testeur manuel décide de ce qu'il regarde.L'enregistrement aussi : quand il s'arrête, il demande ce que ce test doit vérifier.Vérifier les éléments visuels vérifie chaque élément sur lequel vous avez cliqué ou dans lequel vous avez tapé, Vérifier le texte vérifie les mots, et Vérifier ce qui apparaît vérifie les menus, dialogues et messages qui s'affichent sans clic.Que vérifier explique chaque choix.
Chaque vérification porte sur ce que voit l'utilisateur, pas sur la façon dont l'application est construite.Pour trouver chaque élément, le GTS Engine + AI interroge d'abord l'application, et trouve l'élément à la vue quand l'application ne dit rien.Il n'y a aucun sélecteur à écrire ni à tenir à jour.
L'exécuter à chaque build
gtr-cli, l'exécuteur en ligne de commande, exécute un test exactement comme le bouton Exécuter le test et ajoute ce dont un pipeline a besoin : un code de sortie, un fichier JUnit et toutes les preuves d'un échec dans un seul dossier.Il fonctionne avec n'importe quel outil de CI/CD.Exécuter des tests dans votre pipeline liste toutes les options.
gtr-cli run tests --junit results\junit.xmlCe que rapporte une exécution automatisée
C'est ici qu'un test automatisé répond au point le plus faible d'un passage manuel.Chaque exécution écrit un rapport de confiance, conservé avec le test.
Un passage manuel se termine par des coches ; une exécution se termine par des preuves.
Le verdict dit comment l'exécution s'est terminée et, en cas d'échec, à quelle étape et sur quelle vérification.
Chaque vérification échouée montre l'image attendue à côté de ce qui a été trouvé, avec la zone qui a changé mise en évidence.
La vidéo de l'exécution montre chaque étape, y compris celles qui ont réussi.
L'historique compare cette exécution aux précédentes, pour voir quand une vérification a commencé à échouer.
À partir de là, Rapport d'anomalie transforme un échec en rapport rempli ou en ticket Jira, avec les images jointes.Le guide Le rapport de confiance montre comment le lire.
Les tests manuels sont-ils morts ?
Non, et il ne devrait pas l'être.Ce qui se termine, c'est le test de régression manuel : les mêmes vérifications scriptées, parcourues à la main, version après version.Les testeurs qui faisaient ce travail sont ceux qui savent quels scénarios comptent, et c'est exactement ce dont un test automatisé a besoin.
Avec les vérifications répétées automatisées, une équipe QA consacre son temps au test exploratoire, aux nouvelles fonctionnalités et aux questions que seule une personne pose.Les tests tournent à chaque build, et les testeurs examinent ce qu'ils ont trouvé.
Nouveau dans l'outil ?Bien démarrer avec GUI Test Studio montre un premier test du début à la fin.
Points clés
- 1Tests manuels et tests automatisés font des travaux différents : les personnes explorent et jugent, les tests automatisés répètent les mêmes vérifications de la même façon à chaque fois.
- 2Les vérifications fonctionnelles et de bout en bout faites à la main ne suffisent plus quand elles se répètent : elles ralentissent à chaque version, navigateur et langue, et elles ne peuvent pas tourner à chaque build.
- 3La répétition fait rater des choses : même les experts ratent ce qu'ils ne cherchent pas, et deux testeurs vérifient le même cas de test différemment.
- 4Le code a empêché beaucoup d'équipes QA d'automatiser : dans un framework à coder, un test est un programme avec des sélecteurs à écrire et à maintenir.
- 5GUI Test Studio transforme le scénario manuel en test : enregistrez-le une fois ou décrivez-le dans une consigne, exécutez-le à chaque build avec gtr-cli, et lisez un rapport avec des images et une vidéo.
Questions
Quelle est la différence entre test manuel et test automatisé ?
Dans un test manuel, une personne exécute les étapes et décide à l'œil si l'application est correcte.Dans un test automatisé, un test rejoue les étapes et vérifie le résultat tout seul, de la même façon à chaque fois.Le test manuel apporte le jugement, le test automatisé apporte la répétition à grande échelle.
Quels sont les inconvénients des tests manuels ?
Ils sont lents, et ralentissent encore à chaque version, navigateur et langue.La répétition fait rater des choses, deux testeurs vérifient rarement exactement de la même façon, et un passage manuel laisse peu de preuves.Ils ne peuvent pas non plus tourner à chaque build, si bien qu'un bogue est trouvé des jours après son arrivée.
Les tests manuels sont-ils morts ?
Non.Le test exploratoire, le test d'utilisabilité et le jugement restent humains, et les recherches de DORA les recommandent à côté de l'automatisation.Ce qui s'efface, c'est le test de régression manuel : exécuter les mêmes vérifications scriptées à la main, version après version.
Quand faut-il automatiser un test ?
Automatisez un test que vous exécuterez à nouveau : un parcours vérifié à chaque version, dans chaque navigateur ou dans chaque langue, ou un bogue qui ne doit jamais revenir.Gardez une vérification manuelle quand elle demande du jugement, quand la fonctionnalité change encore tous les jours, ou quand elle ne sera exécutée qu'une fois.
Pourquoi automatiser les tests de régression ?
Parce que le test de régression est la même vérification répétée après chaque changement, exactement ce que les personnes font le moins bien et les machines le mieux.DORA qualifie le test de régression manuel de long, coûteux et de goulot d'étranglement.Un test de régression automatisé tourne à chaque build et dit en quelques minutes ce qu'un changement a cassé.
Un testeur manuel peut-il automatiser des tests sans coder ?
Oui.Dans GUI Test Studio, vous enregistrez le test en faisant vous-même le scénario, ou vous le décrivez dans une consigne à un assistant IA.Il n'y a aucun script à écrire ni aucun sélecteur à maintenir, et les vérifications sont choisies après l'enregistrement.
Quels tests doivent rester manuels ?
Le test exploratoire d'une nouvelle fonctionnalité, les revues d'utilisabilité et d'accessibilité avec de vraies personnes, et les vérifications ponctuelles que vous ne referez pas.Elles demandent une personne qui remarque ce que personne n'a prévu.Tout ce qui se vérifie de la même façon encore et encore est candidat à l'automatisation.
Comment transformer un cas de test manuel en test automatisé ?
Prenez un cas de test que vous répétez à chaque version, notez son point de départ, puis enregistrez-le une fois dans GUI Test Studio ou collez ses étapes dans une consigne.Choisissez ce qu'il vérifie, exécutez-le une fois pour le voir réussir, et ajoutez-le à votre pipeline avec gtr-cli pour qu'il tourne à chaque build.
Playwright, Selenium, Cypress, Appium, WinAppDriver, Chrome, Edge, Firefox, Claude, ChatGPT, Codex, Jira et Windows sont des marques de leurs propriétaires respectifs.
À lire aussi
Tous les articles
Automatisation des tests
Tests de bout en bout vs tests d'intégration : ce que chacun attrape (avec des exemples)
10 min de lecture
Automatisation des tests
Alternatives à Appium pour les applications de bureau Windows et Android (2026)
10 min de lecture
Automatisation des tests
Alternatives à TestComplete et à Ranorex : la liste de contrôle de l'acheteur quand la licence arrive à échéance
11 min de lecture