Le rôle de l’automatisation dans le déclin des tests logiciels

L’augmentation de l’automatisation des tests a-t-elle abouti à des versions de produits de qualité moindre ? Outre l’adoption de scripts automatisés plus complets, il convient de tenir compte de la dynamique des processus et de l’organisation.

Par John Tyson, traduit de l’article Better Softaware winter 2018

 

Il y a une tendance dans les tests de logiciels que je n’aime pas. Les équipes de développement préfèrent la rapidité et la légèreté des tests automatisés aux tests de scénarios utilisateur plus profonds et plus réalistes. Auparavant, les testeurs de logiciels étaient appréciés dans le développement de logiciels pour leurs compétences en matière de tests, mais l’obsession de l’industrie pour l’automatisation des tests en est maintenant au point où on pense que les testeurs peuvent être remplacés par des scripts de test automatisés. En conséquence, l’automatisation des tests a besoin de programmeurs et non de testeurs. Les testeurs de logiciels professionnels sont expulsés s’ils n’ont pas de compétences d’automatisation des tests. Cette rapidité laisse peu de temps pour effectuer des tests exploratoires et les tests d’interface utilisateur. Cette tendance survient au pire moment possible, car les logiciels deviennent de plus en plus complexes et critiques.

En mettant trop l’accent sur l’automatisation des tests, nous risquons de réduire le rôle des testeurs de logiciels professionnels comme membres à part entière de l’équipe de développement. Les logiciels de mauvaise qualité ont également un impact sur les utilisateurs, qui peuvent représenter des millions, voire des milliards de personnes. Un logiciel de haute qualité offre une bonne expérience utilisateur tout en réduisant les coûts de support client.

 

Du modèle en cascade à RAD à Agile

Lorsque j’ai commencé ma carrière dans le domaine des tests de logiciels au milieu des années 90, les tests de logiciels étaient devenus la norme dans le développement de logiciels, même s’il restait quelques problèmes à résoudre. Les tests suivaient le modèle en cascade, même pour les projets en RAD, démarrant tard dans le cycle de développement, créant un goulot d’étranglement. Les tests ont souvent été utilisés comme dépotoir pour les programmeurs pauvres, indiquant peut-être que les tests n’étaient pas si importants et constituaient plutôt un élément de contrôle.

À cette époque, les tests logiciels étaient à la hausse, avec de nouveaux outils, de nouvelles techniques et de meilleurs testeurs. Il a été reconnu que les tests et le développement étaient deux compétences très différentes que l’on ne retrouvait pas souvent chez la même personne. Les outils de suivi des défauts et d’automatisation des tests ont commencé à être utilisés. Les discussions sur les tests sont devenues courantes, de même que les discussions sur la testabilité. En outre, il y avait un engagement envers les tests de performance et de charge, les tests d’utilisabilité et les tests fonctionnels.

L’avenir s’annonçait bien pour les testeurs de logiciels. Mais il y avait un problème. Toutes ces discussions sur la qualité ont nécessité investissement et temps. L’automatisation des tests était considérée comme la panacée pour le goulot d’étranglement des tests. Selon l’article de James Bach intitulé « Test Automation Snake Oil » (« le remède miracle de l’automatisation des tests »), les constructeurs d’outils logiciels surestimaient la facilité et l’efficacité de leurs outils d’enregistrement et de lecture d’automatisation des tests. Les testeurs ont trouvé leurs scripts de test automatisés fragiles. Un petit changement dans une application pourrait invalider des centaines de scripts de test. Les gens ont appris à atténuer ces problèmes en adoptant une approche modulaire, basée sur les données, pour les tests automatisés, afin que les scripts puissent être réutilisés et qu’une modification de l’application n’entraînerait que la modification d’un ou deux scripts de test. Cela a permis de réduire le nombre de scripts de test nécessaires.

 

Mais le besoin de rapidité dans la livraison des logiciels a continué d’augmenter, passant de cascade à RAD et maintenant, à agile. Les outils d’automatisation des tests ont souffert de l’obligation de tester l’application avant même que les scripts puissent être enregistrés. Pire encore, les scripts reposaient sur l’interface utilisateur, qui change généralement tard et souvent au cours du cycle de développement, une fois que les utilisateurs ont pu voir et utiliser leur nouvelle application. Pour compliquer encore les choses, plus les fonctionnalités de test des outils d’automatisation sont nombreuses, plus elles deviennent chères.

Pour remédier à tous ces problèmes, des outils open source ont évolués. Selenium WebDriver est actuellement l’un des plus populaires. Selenium a éliminé le problème du coût des licences, tandis que d’autres outils permettaient aux développeurs de coder des tests pour les fonctions situées derrière l’interface utilisateur. Même si l’interface utilisateur change, les scripts de test fonctionnent quand même, car les fonctions sous-jacentes ne changent généralement pas. Des scripts de test peuvent maintenant être développés dès que les fonctions sont disponibles au lieu d’attendre que l’application le soit. Ironiquement, déplacer les tests plus tôt et rendre les scripts plus robustes a marqué la fin des tests de logiciels, l’accent étant mis sur le développement de scripts automatisés plutôt que sur les compétences de test.

 

Les testeurs de logiciels doivent-ils devenir des développeurs ?

Cela nous amène à notre situation actuelle, où l’automatisation des tests est toujours considérée comme la clé pour assurer la qualité du produit. Cependant, ce sont les développeurs – et non les testeurs – qui sont nécessaires pour tester les logiciels. Dans les offres d’emploi, la compétence la plus importante demandée aux testeurs est l’automatisation des tests, qui se traduit par « pouvez-vous programmer ? »

Soit la compétence et l’état d’esprit réels des tests ne sont pas considérés comme importants, soit on suppose que tout le monde peut tester.

Cela aura des conséquences profondément néfastes pour l’avenir de l’industrie du développement de logiciels, car des choses telles que les véhicules autonomes et l’internet des objets deviennent monnaie courante. Remplacer les testeurs par des développeurs n’a peut-être pas été intentionnel, mais c’est devenu une tendance. Les personnes qui écrivent des tests automatisés, en particulier en utilisant une approche derrière l’interface utilisateur, ont généralement des compétences en développement, les programmeurs sont donc le choix naturel.

Certains pourraient dire que la programmation des tests avec du code ou des scripts est une nouvelle compétence que les testeurs doivent apprendre. Cette compétence peut être un atout, car elle permet aux testeurs d’abandonner les tests et de passer au développement de logiciels, où davantage d’emplois sont disponibles et où le salaire – et le respect – est supérieur. Cependant, obliger les testeurs à devenir des développeurs présente de nombreux inconvénients. Voyons les problèmes.

 

Les tests automatisés impliquent généralement des tests superficiels.

L’automatisation des tests a été critiquée pour ne pas avoir répondu aux attentes. Tous les tests ne peuvent pas être automatisés – certains en raison de limitations techniques (telles que des problèmes de synchronisation), d’autres en raison de considérations économiques. Il est tout simplement impossible d’automatiser certains tests. Cela signifie que votre suite de tests automatisés sera un sous-ensemble de ce qui peut être testé. Il y a de fortes chances que ce soit une suite de tests de régression peu profonde et évolutive qui ne couvre pas les scénarios complexes, en particulier si le testeur doit effectuer le test en un seul sprint.

L’automatisation des tests a généralement priorité sur les tests exploratoires plus approfondis. Cela est particulièrement vrai si les tests automatisés sont inclus dans la définition des critères de réalisation.

 

Le test est confondu avec la vérification.

Beaucoup de choses ont été écrites sur la différence entre les tests, qui nécessitent une compétence hautement cognitive, et la vérification d’un ensemble statique d’étapes exécutées par des machines. [2] James Bach et Michael Bolton citent le philosophe Marshall McLuhan, qui écrit : « Nous façonnons nos outils, et ensuite nos outils nous façonnent. » [3] Ils présentent également une analogie : « Nous pouvons être témoins de la façon dont l’industrialisation transforme les artisans dans des usines d’armoires, et cela peut nous inciter à parler du rôle changeant de l’ébéniste, mais celui-ci n’est certainement pas un artisan muté. » Ici, l’ouvrier agit en tant que vérificateur, faisant fonctionner une machine, tandis qu’un artisan un testeur, choisissant de ne pas utiliser de bois endommagé ou de mauvaise qualité, cherchant la raison pour laquelle le coffret n’a pas été fabriqué correctement.

Le contrôle, au lieu de tester, peut également souffrir du paradoxe du pesticide. Tout comme les insectes développent éventuellement une résistance à un pesticide, des tests répétés en utilisant les mêmes données et selon les mêmes étapes omettront très probablement des anomalies que des données ou des étapes différentes pourraient révéler. [4]

 

Il n’y a jamais assez de temps.

Les testeurs sont perpétuellement en mode panique. Cela tient en partie à la nature de la charge de travail infinie des tests par rapport à la charge de travail limitée du développement. La charge de travail du développeur diminue à mesure que le codage est terminé, tandis que la charge de travail du testeur augmente à mesure que davantage de fonctionnalités doivent être testées à l’approche de l’échéance. Les testeurs doivent en apprendre davantage, car il est courant que les testeurs testent une application de bout en bout, tandis que les développeurs se concentrent généralement sur une fonctionnalité ou une petite zone d’une application.

Le nombre de développeurs pris en charge par les testeurs est un autre facteur qui influe sur le temps disponible pour les tests. D’après mon expérience dans les projets de développement agiles, j’ai généralement aidé quatre à six développeurs. Pour que les testeurs puissent comprendre le fonctionnement des fonctionnalités développées, il est nécessaire que les développeurs transfèrent de la documentation et des connaissances. Etant donné que l’agile insiste moins sur le besoin de documentation, il est souvent plus facile de s’écarter du problème et de demander des éclaircissements au propriétaire du produit qui consomme plus de temps du testeur pour des tâches autres que les tests.

La réalité est que les user stories ou les descriptions de tâches sont rarement mises à jour. Si le testeur n’est pas informé, il peut perdre du temps à tester quelque chose qui n’a pas besoin d’être testé. Si le testeur prend en charge plusieurs développeurs, ils peuvent être amenés à travailler à un rythme insoutenable, en violation d’un principe clé de l’agilité.

 

Déterminer si le développement est terminé n’est pas chose facile.

Votre équipe a-t-elle une date limite de gel du développement ? J’ai assisté à des sprints où les développeurs livraient du code le dernier jour du sprint, ce qui limitait considérablement les tests possibles. Pire encore, le responsable souhaite que les testeurs effectuent des démonstrations de fin de sprint.

 

Les testeurs sont toujours une ressource rare.

Est-il plus facile de trouver et d’engager un testeur ou un développeur ? En raison du manque de programmes de tests formels, il existe une grande disparité entre les testeurs de logiciels. Certains ont des antécédents en programmation, tandis que d’autres n’ont aucune expérience de test. Cela ne veut pas dire que l’un est meilleur que l’autre, mais il est difficile de faire appel à un bon testeur. Viennent ensuite les spécialités de test, dans lesquelles un testeur peut être excellent en test d’utilisabilité et très mauvais en test de fonctionnement. Les bons testeurs devraient pouvoir vous dire ce qu’il est bon à tester et, ce qui est tout aussi important, ce qu’il n’est pas bon à tester. En plus d’avoir de bons instincts de test, ils doivent être honnêtes, intègres, posséder une éthique de travail solide et être de bons communicateurs. Ceci est difficile à évaluer dans un entretien.

Les développeurs sont plus faciles à trouver, à qualifier et à embaucher. Pourquoi voudriez-vous jeter un testeur de logiciel talentueux avec des compétences spéciales, difficiles à trouver en les obligeant à devenir programmeur ?

 

Les tests d’interface utilisateur sont négligés.

Si l’automatisation des tests remplace les testeurs humains et que votre application est utilisée par des humains, qui teste l’interface utilisateur ? Qui reçoit des commentaires sur l’expérience utilisateur ? Si les utilisateurs qui accèdent pour la première fois à voir l’application sont au cours des tests d’acceptation, vous aurez un désastre. Rappelez-vous que les modifications de l’interface utilisateur sont fréquentes et tardives.

Si les testeurs professionnels ne se penchent pas tôt sur les problèmes d’interface utilisateur et d’utilisabilité, il y aura des problèmes. Les testeurs sont souvent considérés comme des défenseurs des utilisateurs finaux au sein de l’équipe de développement et comme un lien entre les utilisateurs et l’équipe de développement.

Les tests d’interface utilisateur étant contournés, les développeurs de tests automatisés rempliraient-ils ce rôle ?

Il y a une perte de testeurs.

En plus de ne pas développer des compétences de test et des connaissances d’application supplémentaires, cela introduit un nouveau problème : la perte perpétuelle de testeurs. [5] Le test sera considéré comme un poste temporaire d’entrée de gamme. Aucune expertise en matière de tests ne sera développée, de sorte que les applications seront probablement mal testées.

 

La nouvelle composition d’une équipe de développement logiciel

À une époque où des tests plus approfondis sont nécessaires, nous procédons à des tests plus fréquents et superficiels à l’aide de l’automatisation des tests. Les discussions sur de nouvelles techniques de test plus complètes ont pratiquement disparu. Les produits logiciels testés par la qualité sont une exigence absolue dans l’industrie des applications logicielles. Nous devons reconnaître les forces et les faiblesses des tests automatisés et exploratoires, en utilisant les forces de chacun tout en évitant les faiblesses. Nous devons reconnaître que le test est une compétence spéciale requise pour tous les projets de développement.

L’automatisation des tests est nécessaire. Le test de régression manuel est terriblement ennuyeux, lent et sujet aux erreurs. À mesure que les fonctionnalités nouvelles ou modifiées sont fournies, les tests de régression automatisés sont utiles pour confirmer que les anciennes fonctionnalités fonctionnent toujours correctement. Cela permet également de tester rapidement les fonctions, de fournir des informations plus rapidement et de réduire le nombre de bogues détectés ultérieurement. Les équipes de développement logiciel ont besoin à la fois de testeurs de logiciels professionnels et d’automatiseurs de tests. Cela doit devenir le standard de facto pour le développement de logiciels.

Les testeurs de logiciels professionnels effectueront des tests exploratoires et des recherches approfondies. Ils testeront des éléments que les tests automatisés ne peuvent pas détecter, tels que les problèmes de synchronisation, d’interface utilisateur, de scénarios complexes et de tests économiquement non automatisables. Les équipes de développement de logiciels de demain ont besoin à la fois de spécialistes en automatisation de tests et de spécialistes en tests de logiciels.

 

 

 

Références :

  1. Bach, James. “Test Automation Snake Oil v2.1.” Satisfice(blog). June 13, 1999.http://www.satisfice.com/articles/test_automation_snake_oil.pdf
  2. Rohrman, Justin. “The Debate over Testing versus Checking.” TechWell(TechWell Insights). June 16, 2017.https://www.techwell.com/techwell-insights/2017/06/debate-over-testing-versus-checking
  3. Bach, James and Bolton, Michael, “Testing and Checking Refined,” Satisfice(blog). March 26, 2013.http://www.satisfice.com/blog/archives/856
  4. Beizer, Boris. Software Testing Techniques . 2nd ed. New York: Van Nostrand Reinhold, 1990.
  5. Bonine, Jennifer. “Why Testers Are Starting to Look More like Developers: An Interview with Mike Faulis.” June 30, 2017. https://www.stickyminds.com/interview/why-testers-are-starting-look-more-developers-interview-mike-faulise