Le côté obscur des tests automatisés et pourquoi le manuel reste essentiel
Les tests automatisés sont devenus si essentiels à certaines routines que certains testeurs se demandent s'ils vont complètement remplacer les tests manuels.
Pas de sitôt.
Lorsque l'équipe de Tesla a conçu la Model 3, l’un des moyens envisagés pour augmenter le rythme de production était de disposer d'une chaîne d’assemblage entièrement automatisée. L’IA devait assembler la voiture avec presque aucune supervision humaine.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Le plan a échoué de façon catastrophique.
Les voitures se rentraient dedans, les portes étaient fixées sur les vitres, et les pneus ne se montaient pas correctement sur les jantes.
Que s’est-il passé ? Eh bien, il s’avère que les robots n’y voient pas très clair. L’IA en charge de l’assemblage de la Model 3 n’arrivait pas à s’adapter aux complications imprévues ou aux légers désalignements. Si tout n’était pas parfaitement aligné, elle commettait des erreurs catastrophiques.
Il en va de même pour les tests automatisés en assurance qualité (QA). Certaines formes de tests comportent trop de variables et exigent que le testeur manuel puisse s’adapter et résoudre les problèmes à la volée.
Qu’est-ce que le test automatisé ?
Le test automatisé signifie qu’un testeur QA utilise un outil pour exécuter un cas de test. Lors du cycle de développement, le même cas de test sera vérifié plusieurs fois.
Certains des cas de test qui prendraient des heures à une équipe de testeurs QA peuvent être réalisés par un outil d’automatisation en quelques minutes. Plusieurs outils de tests automatisés sont devenus la norme dans l’industrie.
Le côté obscur du test automatisé
D’autres industries, métiers et professions ont dû gérer l’introduction de l’automatisation dans leur domaine. Chaque fois que cela s’est produit, que ce soit dans l’aviation avec le pilote automatique, le tissage de tapis ou les tests, les travailleurs de ce secteur ont perdu la compréhension du « pourquoi » derrière leur travail.
C’est un phénomène que le professionnel QA, Jan Jaap Cannegieter, a remarqué chez les testeurs. Sa plus grande crainte est que la facilité des tests automatisés et la pression croissante pour automatiser une grande partie du processus mènent à une génération de testeurs qui savent quelles actions exécuter mais ne comprennent pas pourquoi.
Beaucoup de testeurs connaissent tout sur certains outils ou langages de programmation, mais ils ne peuvent pas me dire ce qu'ils testent et pourquoi ils le testent. Et c’est un problème.
Exemples de mauvais tests automatisés
De nombreux testeurs QA voient le même potentiel dans l’automatisation des tests. Cela signifie souvent qu’il y a des tendances observables et des erreurs courantes que peut faire un testeur QA. Voici quelques exemples répandus de mauvais tests automatisés.
Imbrication des tests automatisés
L’imbrication des tests automatisés survient lorsque plusieurs tests automatisés sont exécutés les uns sur les autres. Quand cela arrive, il devient difficile de comprendre ce qui n’a pas fonctionné lorsqu’une erreur apparaît.
À court terme, la plupart des cas de tests automatisés sont positifs. Le testeur QA utilise le bon outil et l’exécute correctement.
Beaucoup d’exemples de mauvais tests automatisés ne deviennent problématiques que six mois plus tard, lorsque des tests automatisés ont été imbriqués les uns dans les autres à plusieurs reprises.
Tests automatisés de l’interface utilisateur sans supervision
Les tests de l’interface utilisateur garantissent qu’aucune action utilisateur sur l’interface ne pourra casser le programme ou entraîner des dysfonctionnements. Réalisé manuellement, cela nécessite beaucoup de testeurs et de main-d'œuvre. C’est, franchement, inefficace de tester ainsi, surtout à mesure que le programme grandit et que davantage de fonctions requièrent des tests.
Avec les tests automatisés, le processus devient plus rapide mais peut toujours nécessiter toute la puissance de l’ordinateur d’un testeur QA pendant une journée entière. Pour y remédier, le testeur QA lance le test à la fin de la journée, le laisse tourner toute la nuit, et retrouve les résultats le matin. Logique, non ?
À première vue, cela paraît être la bonne chose à faire. Le testeur QA utilise son ordinateur pour tester d’autres programmes en journée, puis lance les tests automatisés sur l’interface utilisateur pendant la nuit.
C’est précisément parce que cela paraît logique que c’est une erreur fréquente. Beaucoup de problèmes peuvent survenir quand des tests automatisés s’exécutent sans surveillance.
Si quelque chose tourne mal dès le début, le reste des résultats sera faux. Une journée entière de tests n’aura servi à rien à cause d’une erreur qui aurait pu être facilement repérée et corrigée si quelqu’un avait été là pour vérifier que le test automatisé était correctement exécuté.
Bien que les tests automatisés puissent parfois conduire à des faux positifs, le choix des bons outils d’automatisation QA peut réduire considérablement ce type d’occurrences.
Automatiser les mauvaises choses
Les tests automatisés prennent du temps à mettre en place. Le contrôle qualité doit s’assurer que les outils d’automatisation sont adaptés au projet et que les testeurs QA savent les utiliser correctement.
Tout cela demande beaucoup de temps et d’organisation, et si le résultat final est qu’un test généralement exécuté une fois par mois est automatisé, l’effort n’en vaut pas la peine. Avant de commencer l’automatisation des tests, assurez-vous que ce que vous allez automatiser fera réellement gagner un temps mesurable aux testeurs QA.
Non seulement vous pouvez automatiser des tâches trop rares pour que cela en vaille la peine, mais certaines tâches ne peuvent tout simplement pas être automatisées facilement.
Remplacer les tests manuels
Les tests automatisés ne peuvent repérer que ce pour quoi ils ont été programmés. Si la police d’un site web s’affiche bizarrement, mais que le test ne vérifie que le bon fonctionnement de tous les liens du site, il ne résoudra qu’un seul problème (les liens) sans détecter l’autre (les polices).
Les tests manuels permettent de repérer des problèmes en dehors du périmètre initial du test. La méthode du test exploratoire a été conçue pour donner la possibilité au testeur QA de trouver des bugs inattendus au fil de leur apparition, même si ce n’était pas l’objectif initial. L’automatisation, axée sur une seule tâche, peut être rigoureuse. Ce qu’elle ne peut pas être, c’est exhaustive.
Exemples de bons tests automatisés
L’automatisation des tests est réalisée pour minimiser les risques. Lorsqu’un testeur QA peut à la fois limiter le risque et maximiser l’efficacité, il est entièrement justifié de recourir à l’automatisation. Il n’y a aucune raison pour qu’un testeur QA passe des heures à vérifier manuellement les liens d’un site internet alors qu’un robot explorateur peut effectuer la même tâche en moins de temps et avec moins de risques d’erreur.
Une bonne règle générale pour décider quand utiliser des tests automatisés à la place de tests manuels est de se demander si le test sera rapide ou continu. Si le test doit être exécuté en continu, l’automatisation est alors la meilleure solution.
Les humains sont moins performants que les machines pour répéter des tâches à l’identique et à haut niveau. Nous avons besoin de nouveauté et perdons notre concentration lorsque nous faisons la même chose trop longtemps. Cela laisse place aux erreurs.
Résultat, un testeur QA se rendra compte qu’il a : a) passé plus de temps que s’il avait lancé un test automatisé et, b) fait un travail moins bon, créant plus de problèmes à l’avenir.
Jason Huggins, fondateur du célèbre outil d’automatisation Selenium, a développé le programme parce qu’il a constaté qu’une grande partie de ses journées de testeur était consacrée à exécuter les mêmes tâches — des tâches qu’il jugeait suffisamment simples et directes pour qu’un robot puisse s’en charger. Il a donc créé un script testant automatiquement la fonctionnalité des navigateurs à sa place. Ce fut immédiatement un succès et l’outil est rapidement devenu un standard de l’industrie.
Même les professionnels du QA réticents à l’automatisation reconnaissent qu’elle est, dans de nombreux cas, utile.
Pourquoi les tests manuels ne disparaîtront jamais
Nous avons passé en revue les bons, les mauvais et les très mauvais aspects des tests automatisés. Nous savons dans quelles situations ils sont efficaces et là où ils peuvent perturber sans raison. Prenons un moment pour examiner les tests manuels et comprendre pourquoi ils restent essentiels au travail des testeurs QA.
Les tests automatisés nécessitent une supervision
Comme mentionné plus haut, avec le problème rencontré sur la Model 3 de Musk et les risques liés au lancement de tests automatisés la nuit, les choses peuvent très mal tourner si on laisse seuls les outils d’automatisation.
Les plus grands avantages de l’automatisation sont obtenus lorsqu’elle est réalisée en complément de tests manuels, ou sous la supervision d’un testeur QA. Pour cette seule raison, les testeurs QA peuvent dormir sur leurs deux oreilles : l'automatisation ne risque pas de leur prendre leur rôle dans un avenir proche.
Les tests manuels s’appuient sur les tests exploratoires
Lorsqu’un testeur réalise un test exploratoire, il explore le logiciel sans plan prédéfini. Il s’agit de l’une des formes de test les plus populaires en QA.
Les tests exploratoires ne peuvent être effectués que manuellement.
L’avantage de cette technique est qu’elle permet au testeur de s’adapter immédiatement à ses découvertes, sans avoir besoin d’écrire un nouveau cas de test.
Les tests exploratoires permettent également la collaboration, l’élaboration de théories et une collaboration spontanée en temps réel.
À mesure que la théorie agile du développement est devenue plus répandue, il en a été de même pour les tests exploratoires.
Les tests automatisés manquent de la flexibilité et de la créativité nécessaires pour être assez agiles pour les tests exploratoires. Ils fonctionnent mieux dans un environnement strict où ils savent exactement quoi rechercher. Les tests exploratoires sont tout le contraire : ils demandent au testeur QA d'explorer où bon lui semble.
Qu'en pensez-vous ?
Certaines personnes ne jurent que par les tests automatisés, tandis que d’autres pensent toujours que le manuel est la meilleure solution. Selon vous, comment les équipes QA peuvent-elles tirer le meilleur parti des tests automatisés ? Pensez-vous que nous sommes prêts pour l’IA dans les tests ?
Abonnez-vous à la newsletter du CTO Club pour recevoir les derniers articles et mises à jour d'experts de l'industrie.
