Test manuel ou automatisé : qui fait quoi, et quand ?

Un script peut vérifier cinq cents fois par nuit que le bouton « Valider » envoie bien le formulaire. Il ne vous dira jamais que personne ne trouve ce bouton.

Un testeur humain, lui, sent en quelques secondes qu’un écran inspire la méfiance. Mais lui demander de refaire chaque semaine les mêmes deux cents vérifications, c’est l’épuiser, et laisser passer des erreurs.

Entre « on automatise tout » et « on n’a pas le temps d’automatiser », les deux camps ont tort. Vous allez voir ce que chacun fait le mieux, comment la pyramide des tests aide à répartir l’effort, quand automatiser, ce que cela coûte vraiment, et comment organiser une petite équipe.

Qu’appelle-t-on test manuel et test automatisé ?

Deux idées reçues brouillent souvent le débat.

« Automatisé » ne veut pas dire « sans humain ». Quelqu’un choisit quoi tester, écrit le script, le maintient quand l’app change, et analyse chaque échec. L’outil exécute ; la réflexion reste humaine.

« Manuel » ne veut pas dire « improvisé ». Un test manuel peut suivre des cas de test écrits, étape par étape. Il peut aussi être exploratoire : le testeur conçoit, exécute et évalue ses tests en même temps qu’il découvre l’app. Notre guide du test exploratoire détaille cette méthode.

Enfin, l’automatisation ne se limite pas à « faire cliquer un robot ». La plupart des tests automatisés ne touchent même pas l’écran : ils vérifient une fonction du code, ou une API, l’interface qui permet à l’app de dialoguer avec le serveur.

Que fait mieux un script qu’un humain ?

Un script excelle là où l’humain s’ennuie, se fatigue ou se trompe :

• Répéter à l’identique, dans le même ordre, avec les mêmes données, sans sauter d’étape.
• Aller vite, et donc tourner à chaque modification du code. On parle d’intégration continue (CI, pour Continuous Integration) quand les tests se lancent automatiquement à chaque envoi de code.
• Couvrir de nombreuses combinaisons de données, là où un humain en testerait trois.
• Mesurer précisément : temps de réponse, part du code exercée par les tests.
• Libérer du temps humain pour des tests plus fins.

La documentation Android le dit sans détour : le test manuel passe mal à l’échelle, et il est facile d’y laisser filer une régression. Le test automatisé est plus rapide, plus reproductible, et alerte plus tôt.

Que voit un humain qu’aucun script ne voit ?

Un script ne vérifie que ce qu’on lui a demandé de vérifier. Un humain remarque l’imprévu. Voici ce qu’il capte, et qu’aucun script ne signale :

• L’utilisabilité : on hésite, on cherche, on se trompe de bouton.
• La première impression : l’app inspire-t-elle confiance ? L’accueil est-il clair ? (voir onboarding et première impression)
• Le sens des messages : un script vérifie que « Erreur 402 » s’affiche. Seul un humain vous dira qu’il aurait fallu écrire « Solde insuffisant : il vous manque 2 500 FCFA ».
• Le visuel : un texte qui en chevauche un autre, un prix coupé, un contraste illisible en plein soleil.
• La lenteur ressentie : quatre secondes sans aucun signe de chargement, et l’utilisateur croit l’app bloquée.
• Le contexte réel : une main dans un taxi, un appel qui interrompt, un réseau qui faiblit.

L’ISTQB range d’ailleurs le test exploratoire, le test d’utilisabilité et le test d’acceptation par les utilisateurs parmi les tests orientés utilisateur, souvent manuels. Et même avec une automatisation solide, Ham Vocke, dans son article de référence sur la pyramide des tests, conseille de garder du test exploratoire manuel : il débusque les problèmes de conception, d’ergonomie et de messages peu clairs qui échappent aux scripts.

Les stores eux-mêmes illustrent la limite. Le rapport de pré-lancement de Google Play installe votre app sur des appareils de test, puis un robot l’explore pendant quelques minutes en touchant, en tapant et en balayant l’écran. Il signale plantages, problèmes de performance et d’accessibilité. Il ne vous dira pas si votre inscription est compréhensible.

Qu’est-ce que la pyramide des tests ?

La pyramide des tests, popularisée par Mike Cohn en 2009, aide à répartir l’effort d’automatisation. Sa base regroupe beaucoup de petits tests, isolés et rapides. Plus on monte, plus les tests couvrent un large morceau de l’app, plus ils sont lents et dépendants du reste du système, et moins il en faut. Le nombre et le nom des étages varient selon les équipes.

Le tableau suivant présente les trois étages les plus courants, avec un exemple dans une app de livraison.

Retenez deux règles : écrivez des tests de granularités différentes, et plus vous montez, moins vous en écrivez. L’erreur classique est la pyramide inversée, parfois surnommée « cornet de glace » : presque tout repose sur des tests d’interface lents et fragiles, ou sur de longues campagnes manuelles.

Où se place le test manuel ? À côté de la pyramide plutôt qu’à son sommet. Il ne refait pas le travail des scripts : il critique le produit avec un regard d’utilisateur.

Quand faut-il automatiser ?

Automatisez d’abord ce qui se répète et dont le résultat attendu est précis. Les tests de non-régression en sont l’exemple type : ils sont relancés à chaque version et leur nombre grossit avec le temps. L’ISTQB les désigne comme de très bons candidats à l’automatisation, à commencer tôt dans le projet. Gardez le jugement, la découverte et le ressenti pour les humains.

Le tableau suivant donne le bon réflexe dans six situations courantes.

Évitez d’automatiser une fonctionnalité qui change chaque semaine, un test qui ne servira qu’une fois, ou un prototype qui cherche encore ses utilisateurs. Pour organiser vos campagnes de vérification avant publication, voyez aussi smoke test, régression et recette.

Combien coûte vraiment l’automatisation ?

Un test automatisé n’est pas gratuit une fois écrit. Il faut choisir l’outil et former l’équipe, écrire les tests, les maintenir à chaque changement d’interface, payer l’infrastructure (téléphones, émulateurs, serveurs), et analyser chaque échec pour savoir s’il révèle un bug ou un test cassé.

L’ISTQB liste les pièges classiques : des attentes irréalistes envers l’outil, un temps de maintenance sous-estimé, un outil utilisé là où le test manuel convenait mieux, une confiance aveugle qui étouffe l’esprit critique, la dépendance envers un éditeur, ou un outil libre abandonné par ses auteurs.

Faites le calcul avant de vous lancer. Supposons qu’un parcours de vérification prenne 30 minutes à la main. L’automatiser demande deux jours de travail, puis environ une heure de maintenance par mois. Si vous publiez une fois par mois, le test manuel vous coûte 6 heures par an ; l’automatisation, 28 heures la première année. Mauvaise affaire. Si l’équipe envoie du code dix fois par jour et veut ce contrôle à chaque fois, la balance s’inverse en moins d’une semaine.

Quels outils pour quels tests ?

Le tableau suivant cite des outils répandus, à titre d’exemples et sans préférence : le bon choix dépend de votre langage, de votre équipe et de votre budget.

Gardez en tête un rappel de l’ISTQB : acheter ou installer un outil ne garantit pas le succès. Commencez petit, avec les tests qui vous font gagner le plus de temps, et faites-les tourner régulièrement.

Comment répartir les rôles dans une petite équipe ?

Voici une organisation réaliste pour une équipe de deux à dix personnes :

1. À chaque modification du code : les développeurs écrivent des tests unitaires sur la logique métier (calculs, règles, validations de saisie).
2. Dès qu’un parcours critique est stable : un smoke test automatisé couvre la connexion, le parcours principal et le paiement en mode test.
3. Sur le serveur : des tests d’API automatisés protègent les commandes et les paiements.
4. Avant chaque publication : une session de test exploratoire d’une à deux heures, sur de vrais téléphones, dont un d’entrée de gamme, en données mobiles (voir le test de compatibilité sur appareils).
5. À chaque grande évolution : un test utilisateur avec cinq personnes qui découvrent l’app.
6. Avant de publier sur les stores : des testeurs externes, sur leurs propres appareils et leurs propres réseaux. C’est le rôle de GeekTest, qui vous rend des retours structurés de testeurs réels.

Si vous codez avec l’aide d’une IA, la règle ne change pas : l’IA écrit vite des tests, mais elle ne remplace pas un regard humain sur l’app finie. Nous en parlons dans vibe coding : pourquoi les tests humains restent indispensables.

Avant d’automatiser un test, passez-le au crible de cette liste.

Les scripts gardent ce que vous avez déjà construit ; les humains vous disent si cela vaut la peine d’être utilisé. Une bonne stratégie de test a besoin des deux, et les tarifs de nos formules vous montrent comment ajouter la partie humaine sans recruter.

Pour aller plus loin

• Syllabus ISTQB Niveau Fondation v4.0, en français (CFTL) (nouvel onglet) : la pyramide des tests (section 5.1.6), les quadrants de test (5.1.7), les bénéfices et risques de l’automatisation (6.2), le test de régression (2.2.3) et le test exploratoire (4.4.2).
• Ham Vocke, « The Practical Test Pyramid », martinfowler.com, 2018 (nouvel onglet) (en anglais) : la pyramide des tests appliquée, avec la place du test exploratoire manuel.
• Google Testing Blog : « Flaky Tests at Google and How We Mitigate Them », 2016 (nouvel onglet) (en anglais) : les chiffres de Google sur les tests instables.
• Android Developers : notions de base sur les tests d’applications Android (nouvel onglet) : tests manuels et automatisés, tests locaux et instrumentés, tailles de tests.
• Aide Play Console : le rapport de pré-lancement (nouvel onglet) : ce que l’exploration automatique de Google Play détecte, et comment.