Les pièges de l’automatisation des tests
L’automatisation, finement découpée
Il est indéniable que l’automatisation des tests a révolutionné le test logiciel. Et juste à temps ! Dans le monde actuel, fait de services ultra-distribués, en conteneur, et se mettant à jour en continu, il serait impossible de pratiquer des tests logiciels pertinents sans elle.
Nous avons la chance de disposer aujourd’hui de nombreux outils sophistiqués de test automatisé. Et, permettez-moi d’ajouter, d’excellents ingénieurs QA bien formés pour les exploiter à l’avantage de tous dans l’effort de développement.
Cependant, pour une raison quelconque, c’est dans la nature de notre secteur de réduire systématiquement de telles avancées considérables en des modes, et ces modes en salades de mots creuses et en slogans ressassés mécaniquement par des cadres dirigeants, des experts et des consultants qui cherchent juste à ne plus avoir à réfléchir au problème. Ou à gagner de l’argent rapidement.
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
Il en va ainsi des percées dans l’automatisation des tests, rapidement absorbées dans le récit réducteur du « il nous suffit d’automatiser tous nos tests ! Immédiatement ! Et tous nos problèmes de tests seront résolus ! »
Non seulement c’est une très mauvaise idée, même si elle émanait de personnes désireuses de prendre la question au sérieux et non de l’éviter. Mais ce discours est aussi pernicieux, car il ferme la porte à une véritable réflexion sur la façon d’intégrer l’automatisation dans les efforts de tests, ce qui garantit son échec. Ce qui est injuste pour toutes les personnes (y compris les clients) dont la réussite en dépend.
Sous cet angle, l’automatisation des tests hérite tout simplement d’un travers propre à l’approche générale de la SQA par ceux qui n’en comprennent pas – et ne veulent pas en comprendre – la réalité. Elle est perçue comme un bien de masse, et non comme une compétence complexe. C’est pourquoi, en QA, on entend si souvent de la part de la direction, « il nous suffit d’avoir plus de QA ! » comme s’il existait une charcuterie du logiciel où il serait possible d’en commander au kilo, finement tranché.
C’est ainsi qu’aujourd’hui, le mantra devient : « il nous suffit d’automatiser davantage ! », sans même se demander ce que cela signifierait en pratique dans vos projets de développement logiciel. Ce discours ne fait que nourrir les dysfonctionnements de votre organisation. Il ne les résout pas.
Chercher à s’opposer frontalement à ces mouvements de mode revient à vouloir empêcher le soleil de se lever. Ou, dans ce cas précis, de se coucher. La meilleure stratégie reste alors de hocher la tête et de sourire face aux VP et consultants, puis de retourner dans vos bureaux pour trouver la façon optimale de mettre en œuvre l’automatisation, et enfin de présenter ces idées comme sorties tout droit de l’imagination brillante de vos managers. Mais vous avez sûrement déjà retenu cette leçon pour d’autres sujets.
Alors faisons-le. Voici ma liste des pièges à éviter lors de la mise en place de l’automatisation des tests, et comment les contourner, afin que l’automatisation tienne toutes ses promesses dans vos propres efforts de test.
Périmètre de l’automatisation
La question la plus importante à se poser dès le départ est la suivante : dans quelle partie de vos activités de test l’automatisation est-elle la plus profitable ? Prendre le temps d’y réfléchir vous évitera bien des maux de tête à l’avenir.
Répondre à cette question revient à déterminer quelle part de vos tests doit être automatisée et quelle part doit rester manuelle. Cela surprendra peut-être ceux d’entre vous qui subissent en permanence le prêche du « tout automatiser ! ». N’y prêtez aucune attention, ces gens-là ne savent pas de quoi ils parlent.
Automatiser tous vos tests – si tant est que cela soit possible – serait une très mauvaise décision qui ne pourrait que nuire à vos efforts de test.
Il existe des merveilles que l’automatisation peut accomplir, ce que le test manuel ne saurait faire aussi vite ou à répétition. Mais l’inverse est aussi vrai. Certaines tâches sont bien mieux réalisées par le test manuel, et l’automatisation en est incapable. Quelles sont-elles dans chaque cas ?
Là où le test manuel surpasse l’automatisation, c’est tout simplement sur le facteur humain. Le bénéfice d’un humain patient, effectuant des tests exploratoires approfondis, est impossible à reproduire via l’automatisation. Et je ne parle pas seulement de la découverte de bugs.
Tout le monde peut trouver des bugs. Les clients le font gratuitement en permanence. La réelle valeur ajoutée d’un professionnel QA, c’est cette intuition pour savoir exactement comment casser un logiciel, en particulier pour déterminer comment un client peut détourner le logiciel de son usage prévu, ce qui – souvent avec des résultats catastrophiques – est tout à fait possible.
Un autre avantage du test manuel, c’est qu’ayant découvert un bug, le testeur manuel peut immédiatement s’atteler à déterminer son périmètre et sa gravité. Autrement dit, à affiner les contextes de test (systèmes d’exploitation, scénarios métiers, interactions interservices et dépendances) où il se manifeste spécifiquement, et ceux où il ne le fait pas.
Les scripts de tests automatisés sont très loin de pouvoir faire cela correctement et, du point de vue d’un ingénieur logiciel, c’est pourtant l’information essentielle pour diagnostiquer et corriger un défaut. Un rapport de bug qui se contente de dire « j’ai fait ceci et il s’est passé cela » est inutile à leurs yeux.
Le test manuel est en fait bien plus efficace en termes de temps pour fournir ces informations et, parce que l’interaction avec l’ingénierie est directe et immédiate, il fournit un retour et une analyse des causes bien plus riches en informations.
Oui, chère Virginia, le test manuel n’est pas toujours la méthode la moins efficiente et la plus chronophage pour découvrir, diagnostiquer et corriger des bugs, et valider (ou non) leurs corrections.
Là où l'automatisation possède un avantage évident, cependant, c'est dans les tests continus pour la disponibilité et la stabilité—particulièrement pour les systèmes distribués. Cela est d'autant plus central aujourd'hui compte tenu de notre contexte actuel de développement avec l'intégration et le déploiement continus dans des environnements distribués en temps réel.
L'automatisation est également plus efficace pour ce que l'on pourrait appeler les « tests en masse », où vous avez une immense matrice de milliers de conditions et de variables du système à couvrir afin de vérifier si l'une d'entre elles est totalement défaillante ou risque de faire tomber le système.
La règle de base à utiliser pour guider vos décisions sur la priorité à accorder aux tests manuels ou automatisés est la suivante:
Les tests manuels sont généralement privilégiés pour les premiers tests de nouvelles fonctionnalités et capacités. Les tests automatisés sont clairement les mieux adaptés pour la régression générale continue, ainsi que pour les tests de charge et de performance.
Au cours du cycle de vie d'un produit ou d'un service, le test d'une même fonctionnalité devrait évoluer du manuel vers l'automatisé. C'est un continuum du cycle de vie des capacités. Il ne s'agit pas d'un mur infranchissable, à jamais étanche, sans aucune nécessité de savoir ce qui se passe de l'autre côté. Il faut partir du principe que ce qui est testé manuellement aujourd’hui devra être automatisé avec le temps.
Qualifications d'un ingénieur en automatisation
Il est peut-être inévitable que lors du recrutement d'ingénieurs en tests automatisés, les principales qualifications recherchées seront (a) leur niveau de maîtrise des outils d'automatisation qui leur seront demandés, et (b) la connaissance des langages de script de test utilisés par ces outils.
Mais si ce sont les seules qualifications sur lesquelles vous vous concentrez, vous commettez une grosse erreur. Elles sont nécessaires, mais loin d’être suffisantes pour le rôle d’ingénieur en automatisation.
Pourquoi ? Pour la simple raison que savoir utiliser un outil d'automatisation et rédiger des scripts dans son langage ne vous dit strictement rien sur leur compréhension de l'assurance qualité elle-même.
Malheureusement, il est quasiment rare de voir des ingénieurs en automatisation possédant cette formation ou ce bagage. Ils sont recrutés simplement pour leur maîtrise en script, pas parce qu'ils savent concevoir des tests efficaces et diagnostiques.
Ces qualifications sont en réalité plus importantes que l'expérience des outils et langages d'automatisation qu'ils utiliseront. Ils peuvent les apprendre facilement si besoin. Mais il faut beaucoup de temps et d’efforts pour apprendre à quelqu’un comment concevoir des tests et en interpréter les résultats.
Il serait d’ailleurs préférable de prendre un analyste expérimenté que vous avez déjà et de le former aux outils d’automatisation nécessaires. Ces compétences en automatisation, après tout, sont aujourd’hui devenues une commodité. L’intuition et la perspicacité d’un testeur expérimenté, non.
Automatiser l'ignorance ne fait qu’accélérer l’ignorance, de façon plus répétée, et sabote ainsi l’efficacité recherchée grâce aux tests automatisés.
Normes de conception de l'automatisation
Il va de soi que si vous vous lancez dans un effort d'automatisation des tests à grande échelle, vous devrez d'abord définir les normes générales auxquelles toute automatisation doit se conformer pour être acceptée en test. Pourtant, comme pour nombre d’évidences, il semble que les cerveaux disponibles soient moins nombreux qu’on ne le croit.
Voici ce que ces normes doivent couvrir.
Intelligibilité
Un des mystères frustrants du développement logiciel est son aspect artisanal. Il n’est malheureusement pas rare qu’un ingénieur logiciel vous dise qu’il ne peut pas corriger un bug parce qu’il n’a pas écrit le code où il se situe. C’est comme si le code écrit par un autre ingénieur était dans une langue étrangère qu’il ne comprend pas.
Hélas, cela est tout aussi fréquent dans l'ingénierie des tests automatisés. Je ne compte plus les fois où un ingénieur QA m’a dit ne pas savoir mettre à jour une automatisation de test majeure car il ne l’a pas écrite, ne la connaît donc pas, et est incapable de la comprendre. Quant à l’ingénieur qui l’a écrite, il a quitté l’entreprise il y a deux mois.
Ceci est encore moins acceptable dans le cas des scripts de tests automatisés que pour des codes logiciels mettant en œuvre une logique de conception, et pas simplement l'exécution d’étapes. Pourtant cela reste étonnamment courant.
Cela signifie que, avant d’embaucher une douzaine d’ingénieurs QA pour produire allègrement des centaines de scripts automatisés, assurez-vous d’avoir d’abord défini, et formé sur, des normes d’intelligibilité générale.
Il doit être exigé que tous les scripts de test soient mutuellement compréhensibles par n'importe lequel de vos ingénieurs QA, afin de ne pas dépendre d'une seule ressource, souvent passagère, pour leur maintenance.
Définissez et appliquez un processus d’examen/de validation de tous les scripts automatisés potentiels en fonction de ces normes avant leur déploiement en test.
Maintenabilité
La maintenabilité est étroitement liée à la question de l’intelligibilité, cependant les deux notions sont logiquement et opérationnellement distinctes. Un script de test peut être facilement compris par des ingénieurs de test qui ne l’ont pas écrit et pourtant être structuré de telle façon qu’il est extrêmement difficile à mettre à jour ou à modifier.
Voici un exemple réel.
Chez l’un de mes employeurs, nous préparions l’effort de test pour une mise à jour intermédiaire de leur produit phare. Elle était prévue sur un cycle de publication de quatre semaines, ce qui était raisonnable dans ce cas.
Alors que je planifiais l’effort de test nécessaire, je me suis rendu compte qu’il fallait également mettre à jour le script principal de test de régression automatisé. Lorsque j’ai demandé à l’ingénieur QA principal combien de temps cette mise à jour prendrait, il m’a répondu « huit semaines ». Deux fois le temps de la sortie elle-même ! Même en tenant compte du péché d’ingénierie consistant à gonfler les estimations, c’était extrême.
J’ai fait relire le script et l’estimation par quelques autres ingénieurs de test. Ils étaient tous d’accord pour dire que le script avait été écrit de façon si maladroite et inefficace qu’il faudrait de nombreuses semaines de réécriture fastidieuse de tout le script pour le mettre à jour pour la prochaine version, alors que les mises à jour elles-mêmes n’étaient pas des réécritures fondamentales du produit.
Cette situation était un exemple classique d’un péché d’ingénierie logicielle transporté dans l’ingénierie des tests. Il est temps de mettre fin à cette folie.
Mon conseil ici est identique à celui que je donne plus haut sur la question de l’intelligibilité. Ne laissez jamais, sous aucun prétexte, vos ingénieurs QA s’enfermer dans leur grotte d’ingénierie de test et réapparaître une semaine ou deux plus tard avec quelque chose qui pourrait fonctionner comme un test mais qui sera un cauchemar à maintenir rapidement.
Mettez en place des standards pour garantir la mise à jour rapide et créez un processus de revue et d’acceptation pour s’assurer qu’ils soient respectés. Cela peut facilement être intégré aux efforts en faveur de l’intelligibilité, tout peut appartenir au même processus de revue.
Vos ingénieurs QA ne sont pas des peintres de la Renaissance, vous ne leur demandez pas de repeindre la chapelle Sixtine. Cela ne devrait pas prendre toute une vie.
Rôles de test et automatisation des tests
Un des schémas d’inefficacité qui entrave l’intégration fluide et fructueuse de l’automatisation dans l’ensemble de votre démarche de test est la fausse supposition que chaque étape du processus de test automatisé doit être réalisée exclusivement par le groupe d’automatisation lui-même.
C’est une autre erreur. Même si, dans ce cas, ce n’est pas entièrement évident.
Les ingénieurs en automatisation seront probablement les ressources les mieux payées de votre équipe, donc leur temps est précieux. De plus, le volume de scripts de tests qui devront être créés et continuellement mis à jour par cette équipe ne fera qu’augmenter avec le temps, et pourtant votre vivier d’ingénieurs de test ne pourra pas croître assez vite pour suivre le rythme. Même si vous travaillez chez Google.
Il est alors logique, d’un point de vue opérationnel, de mettre en place une certaine division du travail entre l’équipe d’automatisation et le reste de l’équipe. Plus précisément, la division entre les ressources qui créent et maintiennent les scripts et outils automatisés, et celles qui exécutent réellement les tests automatisés.
Clairement, les premières responsabilités ne peuvent être prises en charge que par l’équipe d’automatisation elle-même. C’est d’ailleurs pour cela qu’ils ont été embauchés. Mais ce n’est pas vrai pour les secondes.
Il n’y a aucune raison pour que les analystes ne puissent pas aussi exécuter les tests automatisés eux-mêmes et interpréter leurs résultats.
Peu de personnes raisonnent ainsi, mais cette division du travail est pleine de sens. D’une part, elle libère une quantité significative de temps pour permettre aux ingénieurs en automatisation de se concentrer sur la création de nouvelles automatisations.
D’autre part, cela renforcera l’exigence d’intelligibilité définie plus haut. Si l’automatisation est au cœur de votre démarche de test, il doit être tout aussi central que chacun dans votre équipe de test, ingénieur en automatisation ou non, puisse comprendre et utiliser vos tests automatisés. Même les testeurs manuels.
Un tel système de définition des rôles augmentera considérablement la flexibilité des ressources de l’ensemble de votre équipe QA et créera donc aussi des gains de temps et d’efficacité de planification qui n’existeraient pas autrement.
Réflexions finales
Développer une solide capacité de tests automatisés, telle qu’elle est définie ci-dessus, est tout simplement une nécessité aujourd’hui. On ne peut pas parler de QA professionnelle et efficace sans cela.
Pourtant, de nombreuses aventures prometteuses démarrent avec enthousiasme et allégresse, pour finir par se solder par un échec à la fin du parcours. Je vois cela arriver dans la QA concernant l’automatisation des tests dans de très nombreux cas.
Le problème est que l’automatisation des tests est relativement facile à débuter. Cher, mais simple de faire semblant de s’y mettre. Cependant, l’automatisation des tests peut aussi être un précipice où, comme Wile E. Coyote dans les dessins animés de Bip Bip et Coyote, on se précipite sans le voir puis l’on chute dès que l’on regarde en bas.
Il faut comprendre dès le départ que l’automatisation des tests a un cycle de vie. Chaque script de test est destiné à vivre des mois, voire des années.
Il ne s’agit pas simplement d’écrire une série de scripts de tests automatisés qui répondent à tous vos besoins sur le produit tel qu’il est à l’instant de son développement. Il s’agit de s’interroger sur la façon dont vous pourrez faire évoluer toute cette automatisation au fur et à mesure que le produit évolue au cours de son propre cycle de vie.
Si vous ignorez les problèmes de périmètre d’automatisation, de qualifications des ingénieurs QA, d’intelligibilité, de maintenabilité et de définition des rôles, vous constaterez qu’avec le temps, tous ces efforts d’automatisation sont devenus un éléphant blanc et un gouffre financier impossible à comprendre ou à maintenir.
Et tout l’argent que vous y avez investi aura été gaspillé. Quelque chose que les supérieurs de vos supérieurs ne manqueront pas de remarquer.
En revanche, si vous suivez les conseils que je donne ci-dessus, adaptés bien sûr à la réalité de vos propres défis et de votre situation, vous éviterez en grande partie cette crise d’obsolescence et profiterez des avantages d’une automatisation des tests productive pour de nombreuses années.
Comme toujours, bonne chance.
Lectures associées :
- 10 MEILLEURS OUTILS DE SURVEILLANCE DE SERVEURS WEB
- MEILLEURES PRATIQUES POUR L’AUTOMATISATION DANS LA TRANSFORMATION NUMÉRIQUE
À découvrir : QU’EST-CE QUE MABL ? APERÇU & TOUR DES FONCTIONNALITÉS
