Qualité & delivery / QA & stratégie de tests
Tests automatisés vs tests manuels : on en parle souvent comme d’un match. En réalité, c’est un duo. Et quand on l’oublie, on se crée des problèmes tout seul.
La fausse question : “est-ce que je dois tout automatiser ?”
Je vois encore trop d’équipes se poser la question en mode binaire : est-ce que je dois tout automatiser, ou est-ce que je fais des tests manuels (voire nearshore/offshore) parce que “ça coûte moins cher” ?
Il n’y a pas de réponse miracle. Et la réponse est presque toujours : oui et non. Le bon choix se trouve entre les deux. Et il dépend d’un truc très simple :
qu’est-ce que vous essayez de sécuriser, à quel moment, et à quel coût ?
Les tests automatisés : accélérer, sécuriser, industrialiser
Les tests automatisés ne sont pas là pour faire joli dans un dashboard. Ils sont là pour rendre la delivery plus rapide et plus sûre.
Ils sont particulièrement efficaces pour :
les parcours répétitifs
les fonctionnalités critiques
les régressions sur des zones stables du produit
Typiquement, sur un e-commerce : le workflow panier → paiement → confirmation est un parcours vital. Celui-là doit être automatisé, point. Parce que si ça casse en prod, ce n’est pas “un bug”, c’est directement une perte de chiffre d’affaires.
Les tests manuels : explorer, valider, apprendre
Les tests manuels ne sont pas “moins bien”. Ils sont juste faits pour autre chose. Ils sont indispensables quand :
le produit est en construction
l’UI bouge beaucoup
les parcours ne sont pas encore stabilisés
on doit valider une expérience utilisateur
En début de projet, automatiser trop tôt peut être contre-productif. Parce que si l’interface change toutes les deux semaines, vous passez plus de temps à réparer vos tests qu’à livrer de la valeur.
Le test manuel sert aussi à vérifier ce que l’automatisation ne voit pas bien : cohérence d’affichage, ressenti, clarté d’un parcours, compréhension côté métier.
Le bon moment pour décider : pendant les specs (pas après)
Le meilleur moment pour trancher, c’est au moment où vous rédigez vos spécifications et votre plan de test.
Quand vous écrivez vos cas de test, vous voyez tout de suite :
ce qui est facilement automatisable
ce qui est fragile (UI instable, règles qui bougent)
ce qui est critique pour le business
Et ça vous évite un piège classique : automatiser “par principe” au lieu d’automatiser “par valeur”.
Automatiser d’abord le simple et le critique
S’il fallait donner une règle simple : automatiser ce qui est simple à automatiser, et ce qui est critique à sécuriser. Pas besoin de viser une couverture énorme dès le départ.
La première étape est souvent :
un socle de tests critiques (smoke tests)
quelques parcours end-to-end essentiels
les tests de non-régression sur les zones stables
Est-ce qu’un testeur doit être développeur ?
C’est une vraie question, et là aussi, la réponse n’est pas binaire. Oui, certains outils demandent une approche “dev” : écrire des tests Cypress, Playwright, etc.
Mais attention : si votre stratégie QA repose uniquement sur des tests codés, alors votre équipe QA devient aussi une équipe d’automatisation. C’est un métier à part entière.
À l’inverse, certaines équipes utilisent des outils “low-code” comme Tosca qui permettent de créer des scénarios automatisés sans être développeur au sens classique. Le point clé, ce n’est pas le titre. C’est la capacité de l’équipe à produire des tests fiables, maintenables et utiles.
Le piège du “tout test” : quand la couverture devient une dette
Je vais être très franc : j’ai déjà vu des projets où on était “fiers” d’avoir plus de 80% de coverage. Sur le papier, c’est impressionnant. Dans la réalité, c’était devenu très difficile à faire évoluer.
Chaque changement fonctionnel faisait exploser une partie des tests, et l’équipe passait son temps à réparer au lieu de livrer. Le but n’est pas d’avoir “le plus de tests possible”. Le but est d’avoir : les bons tests, au bon endroit, au bon moment.
La stratégie mature : complémentarité, pas opposition
Une stratégie QA mature ressemble à ça :
- Tests automatisés sur le critique et le répétitif
- Tests manuels sur l’exploration, l’UI, l’expérience
- Automatisation progressive quand le produit se stabilise
- Une décision prise dès les specs, pas à la fin
Conclusion
Tests manuels vs tests automatisés, ce n’est pas un match. L’automatisation est indispensable pour sécuriser et accélérer, mais elle a un coût de mise en place et de maintenance.
Le test manuel est indispensable pour explorer, valider et apprendre, surtout quand le produit bouge. Le bon équilibre se décide tôt, pendant les specs, en fonction du business, du budget et de la maturité de l’équipe.
L’objectif n’est pas de “tester plus”. L’objectif est de tester mieux.
