L’automatisation des tests, une étape cruciale pour votre site e-commerce

Pourquoi recourir à des tests automatisés ? 

Dans les logiciels, tout s’entremêle, et une petite modification à un bout risque d’avoir un impact potentiellement destructeur à l’autre bout. Pour les systèmes forts interdépendants, il est nécessaire d’effectuer un testing approfondi. Chaque fois que vous changez quelque chose, l’ensemble du projet doit être testé : c’est ce qu’on appelle un test de régression.  

Comme vous pouvez l’imaginer, un test de régression est gourmand en temps et en ressources, mais ce n’est pas le seul problème. Quand vous travaillez sur un projet logiciel en tant que testeur et que vous vous retrouvez à remplir le même formulaire pour la centième fois, vous finissez par vous lasser et perdre en concentration, laisser passer des erreurs. C’est ici que l’automatisation des tests entre en jeu.  

Dans cet article, nous vous expliquons comment fonctionne l’automatisation des tests, quels défis y sont associés et comment procéder pour les acteurs du e-commerce. 

Qu’est-ce que l’automatisation des tests et comment ça fonctionne ? 

L’automatisation des tests consiste à créer des programmes qui simulent l’interaction des utilisateurs avec une application. C’est donc la solution parfaite pour vos tests de régression. Il vous suffit de lancer ces programmes et ils effectueront tous les tests selon des flux prédéfinis, puis vous indiqueront où ils ont rencontré des problèmes.  

Je me souviens d’un projet sur lequel j’ai travaillé, où les développeurs avaient oublié de formater les dates dans un tableau. Au lieu de la date, le tableau affichait le nombre de secondes écoulées depuis 1970. Aucun de nous ne l’avait repéré. Après un certain temps, le cerveau est satisfait dès qu’il voit des chiffres. Les tests automatisés, eux, ont détecté l’erreur, et ils ont même vérifié si chaque date était correcte. 

Au moment de configurer vos tests automatisés, vous devez réfléchir à quasiment toutes les actions possibles pour un utilisateur de votre site. Ensuite, dans l’idéal, vous programmerez un test pour chacune de ces actions. Bien sûr, la plupart du temps, vous laisserez juste des tests automatisés s’exécuter sous forme d’un processus de bout en bout, en les faisant par exemple sélectionner un produit, le mettre dans le panier, entrer des données personnelles, choisir une méthode de livraison et de paiement, puis vérifier si la commande est bien passée.

Les défis des tests automatisés  

Cependant, tout cela a bien entendu un coût. En effet, les tests automatisés doivent être créés étape par étape. Tandis qu’un testeur manuel peut simplement naviguer dans une application en cliquant selon ses besoins, un test automatisé doit être élaboré de façon très minutieuse.  

En tant que testeur ou utilisateur humain, vous pouvez facilement fermer une fenêtre pop-up qui apparaît, mais un test automatisé doit y avoir été préparé. Il doit savoir quand cette fenêtre va apparaître et quand il peut la fermer ; dans le cas contraire, il sera bloqué.  

Créer ces tests vous demandera du temps. Or, ils ne peuvent être créés qu’au moment où une version stable de l’application est disponible ; les spécialistes de l’automatisation de tests se retrouvent dès lors fréquemment coincés dans une sorte de no man’s land entre la création de nouvelles fonctionnalités et leur publication. 

Une fois le développement terminé, quand tout est prêt, les chefs de projet ont généralement envie de livrer le produit le plus vite possible et il ne reste parfois plus de temps pour l’automatisation des tests. Voilà une autre raison qui explique pourquoi cette étape est souvent négligée. 

Pourquoi les acteurs du e-commerce optent pour l’automatisation des tests 

De nos jours, de plus en plus d’entreprises comptent néanmoins sur l’automatisation des tests. Et selon moi, si vous êtes dans le e-commerce, vous feriez mieux de fuir les éditeurs de logiciel qui n’ont pas recours à des tests automatisés. Car négliger l’automatisation des tests, c’est négliger la qualité.  

Bien sûr, vous pouvez essayer de tout tester manuellement à grands coups de clics, et ça suffira probablement pour détecter les gros problèmes. Mais c’est un peu comme demander à votre mécanicien de jeter un coup d’œil rapide sous le capot pour vérifier s’il y a bien un moteur et s’il a l’air en ordre : je vous déconseille de prendre le volant ensuite. Et imaginez maintenant qu’il soit question d’un avion… Évidemment, les applications web comportent moins de risques, mais pensez-y : un client qui tombe plusieurs fois sur un bug ne va pas s’acharner et préférera se rendre sur le site d’un concurrent.  

La maintenance, un frein à l’automatisation des tests ? 

Les spécialistes de l’automatisation de tests s’embourbent souvent dans la maintenance. Les tests automatisés ne sont pas un outil parfait qu’il suffit de démarrer pour voir apparaître le nombre exact d’erreurs dans votre application et leur localisation. Oui, ils détectent les erreurs, mais ils rencontreront également beaucoup d’échecs qui ne seront pas forcément des erreurs.  

Les tests automatisés sont des créatures très fragiles. Ils doivent interagir avec les mêmes éléments qu’un utilisateur, mais si l’un de ces éléments est altéré, ils ne parviendront plus à le trouver. Comment est-ce possible ? Prenons un exemple simple. Disons que nous avons un bouton pour continuer après avoir sélectionné une méthode de paiement, et qu’il est associé au code HTML suivant : 

<button class=”continue”> 

Puisqu’une page peut contenir beaucoup de boutons, les tests automatisés seront programmés pour chercher un bouton associé à la classe « continue ». Mais imaginons maintenant que cette classe change et que nous ayons ceci : 

<button class=”continue_payment”> 

Dans ce cas, le test automatisé ne trouvera plus le bouton et indiquera dans son rapport qu’il y a un bouton manquant. Le test conclura sur un échec. Or, ce résultat ne serait pas pertinent d’un point de vue fonctionnel, puisque le bouton est bien présent. Une maintenance sera alors nécessaire pour adapter le test au nouveau bouton.  

Souvent, ce besoin élevé en maintenance découle d’un manque de synchronisation entre spécialistes de l’automatisation et développeurs. Les spécialistes de l’automatisation ne sont pas toujours prévenus des changements apportés à l’application. Et de leur côté, les développeurs ne savent pas forcément quels éléments les spécialistes de l’automatisation utiliseront pour leurs tests. Les tests automatisés sont particulièrement éprouvés quand le design a subi beaucoup de modifications, car celles-ci entraînent de nombreux changements mineurs de ce genre.  

Les tests automatisés raffolent en revanche des longs formulaires monotones qu’ils remplissent si vite que nos yeux n’arrivent pas à suivre. Ces tests pourront être exécutés à l’infini, tant que vous ne touchez pas aux champs. Les jungles de fenêtres pop-up représentent un autre obstacle pour les tests automatisés, incapables d’interagir avec les éléments cachés derrière.  

En tant qu’utilisateur, vous pouvez facilement fermer la fenêtre d’un simple clic. Mais un test automatisé doit d’abord attendre qu’elle apparaisse, même si elle n’est pas encore là, puis la fermer, et ce n’est qu’alors qu’il peut commencer à interagir avec les éléments de la page. Vous vous en doutez, c’est particulièrement compliqué quand ces fenêtres ne sont pas systématiques et qu’elles peuvent ne pas apparaître. 

La solution pour que tout fonctionne 

Heureusement, il existe une solution à tous ces problèmes de maintenance, et elle s’accompagne d’un bonus magique. Si les développeurs savaient sur quels éléments s’appuient les spécialistes de l’automatisation, tout se passerait bien. Et ça, ça peut être fait à peu de frais. Les développeurs pourraient simplement ajouter ces éléments. Reprenons l’exemple du bouton utilisé plus haut. Nous pourrions y ajouter un attribut spécial pour l’automatisation :  

<button class=”continue” auto=“continueAfterPayment“> 

Ainsi, les tests pourraient se référer à cet attribut spécial sans être affectés par les changements apportés aux autres attributs ou même à l’élément lui-même – le bouton pourrait par exemple être transformé en lien pour des raisons de design. Et si tous les éléments interactifs d’une page comportent un de ces attributs dédiés à l’automatisation, les tests deviennent alors très stables. Mais évidemment, cette solution représente un surplus de travail pour les développeurs, et elle a peu de chance d’être implémentée si l’automatisation n’est pas perçue comme une part importante du processus de développement.  

Il y a d’ailleurs un aspect qui montre bien à quel point l’automatisation n’est pas prise en considération pendant le développement. Durant leur formation, les spécialistes de l’automatisation apprennent souvent à s’appuyer sur des id d’éléments qui ressemblent à ça : 

<button id=”continue”> 

Ces attributs id sont supposés stables et uniques sur une page, et de nombreux outils d’automatisation intègrent même des références toutes faites à ces id. Par exemple, dans Selenium, un outil standard pour l’automatisation des tests, vous pouvez demander à l’ordinateur de retrouver un élément grâce à son id. En revanche, si vous voulez utiliser la classe, comme dans l’exemple présenté plus haut, les choses se compliquent. Or, de nombreux environnements de développement génèrent ces id de manière automatique et absolument pas cohérente. Ils deviennent donc complètement inutiles pour l’automatisation. Bref, ces deux mondes ne sont pas vraiment en phase à ce niveau. 

Un lien magique entre développement et automatisation 

Vous vous souvenez de cet élément magique que j’ai mentionné plus haut ? Imaginez une page web sur laquelle tous les éléments fonctionnels auraient un attribut fixe auquel les tests automatisés pourraient se référer, comme nous l’avons vu dans notre exemple : 

<button class=”continue” auto=“continueAfterPayment“> 

En soi, l’automatisation des tests est une procédure relativement simple. Elle transpose simplement des descriptions d’étapes de tests fonctionnels en descriptions d’étapes de tests automatisés. « Cliquez ici, puis remplissez ce champ et cliquez là ». Le plus compliqué quand il faut l’expliquer à un programme, c’est de lui faire comprendre quels éléments sont associés à « ici » et « là », sur quel bouton il doit cliquer ou quel champ il doit remplir. Mais maintenant, imaginez que ces éléments disposent d’une sorte de référence fixe, comme dans l’exemple ci-dessus. Dans ce cas, détecter cette référence devient une étape simplissime qu’un programme peut exécuter lui-même. Cela signifie qu’on pourrait alors automatiser le référencement. Et ça, cela signifie qu’on pourrait automatiser l’automatisation des tests elle-même. Il nous suffirait d’écrire les scénarios de tests dans un langage plutôt formel, et les scénarios de tests automatisés pourraient ensuite être générés automatiquement à partir de là. Résultat : une automatisation automatisée ! 

Un de mes anciens patrons, qui ressemblait à Léonard de Vinci et pensait beaucoup comme lui, disait toujours que la production de logiciels en était encore plus ou moins à l’âge de pierre, où chaque pierre est produite individuellement et est différente des autres. Il évoquait toujours un avenir dans lequel le développement de logiciel serait plus industrialisé, où les humains ne coderaient plus du tout, et où tout serait généré à partir de modèles. Les interfaces utilisateur et les tests automatisés pourraient alors être générés à partir de ces mêmes modèles et seraient parfaitement compatibles. Mais nous savons tous que les outils de l’âge de pierre étaient considérés comme le nec plus ultra pendant des millions d’années, avant d’être remplacés par le métal il y a quelques millénaires à peine. Nous avons encore beaucoup de chemin à parcourir avant d’atteindre cet idéal de l’automatisation complète. Ce n’est toutefois pas une mauvaise chose de garder ces idées à l’esprit quand on réfléchit aux améliorations possibles.