LeSS - Automatisation des tests

Auteur : The LeSS Company B.V.
Source : Test Automation

---

Traducteur : Nicolas Mereaux
Relecteur : Fabrice Aimetti
Date : 06/11/2022

---

Traduction :

LeSS - Portail Excellence technique

Tests manuels

Les développeurs agiles mettent en avant l’importance des tests automatisés. En effet, avec des cycles courts, l’exécution manuelle des tests de régression s’avère quasiment impossible. Cela signifie t’il qu’il n’y a pas du tout de tests manuels ? Non. Certains tests manuels sont toujours recommandés, même si ces tests diffèrent quelque peu des tests manuels faits à l’aide de scripts.

Automatiser les tests manuels

Les affirmations « Il est impossible d’automatiser des tests de pertes de connexion réseau » ou « Il est impossible d’automatiser des tests portant sur un problème matériel » reviennent souvent de la part des groupes produits. Notre réponse est généralement « Non ce n’est pas vrai » ou « Oui, vous pouvez faire ces types de tests. »

Elisabeth Hendrickson, l’auteur du mini-livre (vo) Exploratory Testing in an Agile Context ose d’ailleurs dire

Je pense que si vous êtes en mesure d’écrire un script de test manuel, c’est que vous êtes aussi en mesure de l’automatiser.

Il peut s’avérer difficile d’automatiser un test exactement de la même manière que s’il était fait manuellement. Par exemple, il est quasiment impossible de débrancher automatiquement un câble réseau pour un cas de test de perte de connexion. Par conséquent, un test automatisé se fait généralement de manière différente. À la place de débrancher physiquement un câble, le test automatisé va instruire le pilote réseau de répondre comme si le câble réseau avait été débranché.

Est-ce que ça vaut le coup d’automatiser tous les tests ? Selon Elisabeth Hendrickson :

Si un test est suffisamment important pour être scripté, et exécuté, il est alors suffisamment important pour être automatisé.

Pourquoi cela ? Le développement itératif et incrémental implique que le code ne soit pas figé en fin d’itération mais qu’il ait, à la place de cela, le potentiel d’être changé à chaque itération. Par conséquent, faire du test de régression manuel signifierait ré-exécuter la majorité des tests manuels à chaque itération. Il va sans dire que l’automatisation s’avère rentable rapidement.

Cela s’avère être particulièrement vrai sur le développement à grande échelle qui prône, entre autres, des équipes features et la propriété collective du code, et pour lequel le filet de sécurité offert par les tests automatisés est d’une importance capitale.

Faire quelques tests manuels

Automating all tests might not be worthwhile or even possible. These tests may need to be done manually:

Automatiser tous les tests pourraient ne pas valoir le coût voire même être possible. Certains tests tels que ceux évoqués ci-dessous devront alors être faits manuellement :

• Tests requiring human opinion and creativity –A person is needed to judge whether the interface looks good–usability testing. Exploratory testing by definition needs someone to decide the next step to explore.
• Tests requiring physical movement –For example, tests with the system in different physical configurations. These can be automated with simulation, but the real configuration might be needed for the final test run.
• Expensive tests –Running capacity tests on the production environment may be too expensive and is therefore done only once or twice. This delays risk. These risks should be tackled early with cheaper tests–for example, running capacity tests on a simulated environment–so that running the expensive test is merely a final check.
• Les tests nécessitant de l’attention et de la créativité de la part de quelqu’un, c’est-à-dire d’une personne capable de juger si l’interface s’apprête bien à des tests d’utilisabilité. Les tests exploratoires, par définition, ont besoin de quelqu’un pour décider de la prochaine étape à explorer.
• Les tests nécessitant une action physique, par exemple dans le cas de tests d’un système ayant des configurations matérielles différentes. Cela peut être automatisé par le biais de la simulation, mais la vraie configuration matérielle pourrait s’avérer nécessaire pour l’exécution du test final.
• Des tests coûteux par nature. Par exemple, exécuter des tests de capacité en environnement de production peut s’avérer trop coûteux et par conséquent ne sont exécutés tout au plus qu’une ou deux fois au cours de la vie du produit. Toutefois, ces tests ne font que retarder le risque. Il est nécessaire de s’attaquer à ces risques le plus tôt possible avec des tests moins coûteux - par exemple, en exécutant des tests de capacité sur une simulation de l’environnement cible - cela permettra que l’exécution du vrai test, qui lui est coûteux, ne soit que la vérification finale.

No false dichotomy: Try to automate all tests, but do not forget to do the manual tests when needed.

Pas de fausse dichotomie : Essayez d’automatiser tous les tests, mais n’oubliez pas de faire des tests manuels lorsque c’est nécessaire.

Faire des tests exploratoires

In Perfect Software and Other Illusions about Testing, Gerald Weinberg calls it, “The Exhaustive Testing Fallacy, that it’s possible to test everything!” It is not. The number of possible scenarios to test is infinite and therefore automating all tests means infinite automation effort. Instead, automate all the anticipated tests and spend time as efficiently as possible on manual exploratory testing to find unforeseen cases.

Dans son ouvrage Perfect Software and Other Illusions about Testing Gérald Weinberg évoque : « l’idée reçue quant à l’exhaustivité des tests, autrement dit il est possible de tout tester ! ». Ce n’est pas le cas. Le nombre de scénarios possibles à tester est pour ainsi dire infini et par conséquent automatiser tous les tests demanderait un effort d’automatisation infini. Essayez donc plutôt d’automatiser les tests déjà envisagés et consacrer du temps aussi efficacement que possible sur les tests exploratoires pour trouver des cas de tests non envisagés.

over-view of exploratory testing

Vue globale du test exploratoire

https://less.works/img/test_automation/xet.png.pagespeed.ic.JppUJEJMw2.png

Tests exploratoires

What is exploratory testing? “Simultaneous learning, test design, and test execution” [Bach03]. This is in contrast to traditional scripted testing where test-case design and execution are separated and sequential steps—first design then execution. Exploratory testing aims at fully utilizing human creativity during test execution, using feedback and observations rather than mindlessly following a script. In exploratory testing, the tester is exploring the system, learning about it and using that information to make test-design decisions. It is best explained by an example.

Qu’est-ce que le test exploratoire ? Dans un de ses articles James Bach le définit comme étant « la combinaison de l’apprentissage, de la conception de tests et de l’exécution de tests en simultané » – Bach03(vo)(http://www.satisfice.com/articles/what_is_et.shtml). Cela vient en contraste avec le test scripté traditionnel dans lequel la conception des cas de tests et l’exécution se font de manière séparée et séquentielle avec d’abord la conception et après l’exécution. Le test exploratoire a pour objectif d’utiliser le plus possible la créativité humaine lors de l’exécution des tests, d’en tirer des informations et de les utiliser pour prendre des décisions relatives à la conception des tests. Cela sera plus clair à l’aide de l’exemple suivant :

Imagine that Gita is testing a 2D modeling application. First, she defines the goal of her test session—in exploratory testing this is called a mission or charter. Her charter is “Explore changing shapes by dragging the control points.” She takes a shape, drops it on the canvas, and creates a couple of control points on it. She drags one of them and observes what happens. Based on this observation (learning), she determines the next step (design) and performs it (execute). The shape takes its new form, though she notices—while dragging the control points—that the shape temporarily took a form that it probably should not have. Therefore, she continues dragging it and moving it around until she can reproduce the accidental transformation.

Imaginons que Gina soit en train de tester une application de modélisation 2D. Tout d’abord, elle commence par définir l’objectif de sa session de test exploratoire que l’on appelle une mission ou une charte. Sa charte est d’ « Explorer les changements de formes en déplaçant les points de contrôle ». Elle sélectionne une forme, la place sur le canevas, et y ajoute deux points de contrôle. Elle déplace l’un d’entre eux et observe ce qu’il se passe. En se basant sur ses observations (apprentissage), elle détermine quelle sera la prochaine étape (conception) et la réalise (exécution). La forme prend un nouvel aspect même si elle remarque que lors du déplacement des points de contrôle la forme a pris temporairement un nouvel aspect qu’elle n’aurait probablement pas dû avoir. Aussi, elle continue à les déplacer et à les déplacer jusqu’à ce qu’elle arrive à reproduire ce type de transformation accidentelle.

In the example, there is no detailed preconceived script or test case but instead an area of focus—a charter. The first step is to observe the system, and the next action is determined from that observation—this is test design. All traditional test techniques and heuristics are applied during this design step.

Dans cet exemple, il n’y a pas de script détaillé préconçu ou de cas de test mais plutôt un périmètre de test — une charte. La première étape est d’observer le système et à partir de cette observation de déterminer l’action suivante à savoir la conception des tests. Toutes les techniques traditionnelles de tests et tous les heuristiques traditionnels de tests sont utilisés lors de cette phase de conception.

https://less.works/img/test_automation/xet_scripted_difference.png.pagespeed.ic.X0uMS-HZ2g.png

Tests exploratoires

Test automatisé

Créer des tests maintenables

“Automated tests will increase our test maintenance load” is a common objection we hear. Test maintenance will cost some effort, but a few straightforward techniques can minimize this cost:

« Les tests automatisés vont augmenter notre charge de maintenance des tests » est une objection que nous entendons régulièrement. Il est certain que la maintenance des tests vous coûtera un peu mais quelques techniques simples peuvent minimiser ce coût :

• remove duplication in and between tests
• delete tests
• do not test through the UI
• run tests frequently
• supprimer toute duplication à l’intérieur et à l’extérieur des tests
• supprimer les tests
• ne pas tester à travers une IHM
• exécuter les tests fréquemment

Supprimer toute duplication à l’intérieur et à l’extérieur des tests

Code duplication causes extra complexity, obscurity, and defects—resulting in extra maintenance effort. This is as true for test code as it is for production code. Avoid this by removing the duplication.

La duplication du code engendre un niveau de complexité, d’incertitude et d’anomalies supplémentaires — ayant pour conséquent un effort de maintenance supplémentaire. C’est vrai tout autant pour le code de test que pour le code en production. Vous pouvez vous éviter cela en supprimant toute duplication de code qui serait présente.

Workflow tests are a common cause of duplication. They often consist of one mother scenario and multiple derived cases with only slight variations in them. When one step changes, all these workflow tests need to be updated. This duplication can be avoided by data-driven tests that focus on business rules or by separating the duplication into test libraries or fixtures.

Les flux de travail de tests sont une forme répandue de duplication. Ils se présentent le plus souvent sous la forme d’un scénario parent avec tout un ensemble de cas de tests dérivés avec par ici ou par là quelques légères variations. Tous ces flux de travail de tests doivent être mis à jour. Ce type de duplication peut être évité avec des tests pilotés par les données qui se focalisent sur les règles métiers ou en séparant les éléments dans des bibliothèques de tests ou des fixtures.

We coached a team that made a common mistake—they delayed their test automation until the end of the iteration. Four days remaining and only automation tasks left. In the previous iterations, these tasks were done by the test specialist, but now they had to be done by the whole team.

Nous avons accompagné une équipe qui avait fait une erreur assez répandue au sein de beaucoup d’équipes — elle avait repoussé l’automatisation des tests à la fin de son itération. Il lui restait 4 jours avant la fin de l’itération et uniquement des tâches d’automatisation à faire. Lors de son itération précédente, ces tâches avaient été faites par un spécialiste des tests mais ces tâches devaient être faites dorénavant par l’ensemble de l’équipe.

They started with a one-day workshop in which the one specialist coached the other team members. After that, they split into two pairs and one triplet working in parallel on automating the tests. Something interesting happened: The team members who were experienced in programming complained about the extra effort needed because of the duplication in the tests. Previously, none of them had noticed it and the test specialist—who did not have much programming experience—never cared. Now that the whole team was involved, they cared and the quality of the tests improved immensely.

Nous avons fait démarré l’équipe avec un atelier d’une journée au cours duquel un spécialiste a formé et accompagné les différents membres de l’équipe. Après cet atelier, l’équipe s’est scindée en plusieurs groupes de deux personnes plus un groupe de trois personnes pour travailler sur l’automatisation des tests. Quelque chose d’intéressant s’est produit : les développeurs expérimentés de l’équipe se sont plaints du surcroit de travail nécessaire à cause de la duplication présente dans les tests. Avant ça, aucun d’entre eux ne l’avaient remarqué et le spécialiste des tests — qui n’avait pas beaucoup d’expérience en programmation — ne s’en était jamais soucié. Maintenant que toute l’équipe était impliquée, tous le monde s’en souciait et la qualité des tests s’est alors grandement améliorée.

Supprimer des tests lorsqu’ils n’apportent aucune valeur

Tests serve multiple purposes. They act as requirements, as verification, and as a safety net preventing system regression.

Les tests servent plusieurs objectifs. Ils servent d’exigences, de vérifications et font aussi office de filet de sécurité pour prévenir la régression du système.

When an existing test is not needed anymore—because it is a subset of another test—then delete it. Leaving unnecessary tests brings no benefit but still increases maintenance effort and lowers test execution speed.

Lorsqu’un test existant n’est plus nécessaire — sachant qu’il n’est qu’une sous-partie d’un autre test — supprimez-le. Ne pas supprimer les tests superflus n’apportent rien mais augmentent par contre le travail de maintenance et diminuent la vitesse d’exécution des tests.

Éviter de tester à travers une IHM

User interfaces (UIs) tend to change frequently. Running your tests through the UI makes them vulnerable to these changes—even when there is no change in test logic. This increases the test maintenance effort.

Les interfaces utilisateurs (ou IHM) ont tendance à changer fréquemment. Exécuter vos tests à travers une IHM les rend vulnérables à ces changements, même s’il n’y a aucun changement dans la logique du test, cela augmente la charge de maintenance des tests.

Therefore, avoid testing through the UI and instead call the application logic directly through an API. Another advantage of doing this is that it speeds up your test since testing through the UI is slow.

Par conséquent, éviter de tester à travers une IHM et faites plutôt appel directement à la logique applicative à travers une API. Un autre avantage de faire cela est d’accélérer la vitesse d’exécution de vos tests car tester à travers une IHM s’avère généralement toujours très lent.

Exécuter les tests fréquemment

Long ago, we worked with a large group following waterfall develop- ment. Traditional test automation advice is to select and automate only the most important cases—with a separate automation team— after the release. So they did. At the end of the next release, they executed the tests and… they all failed. Updating them would take much time, so they decided to do all testing manually.

Il y a longtemps, nous avons travaillé avec une grosse équipe travaillant selon une approche en cascade. Le conseil habituel en automatisation de test est de sélectionner et d’automatiser uniquement les cas de tests les plus importants — par une équipe dédiée à l’automatisation des tests — après la livraison. Ils ont donc fait ça. À la fin de la livraison suivante, ils ont alors exécutés les tests et … ils ont tous échoués. Mettre à jour tous les tests aurait pris trop de temps, alors ils ont décidé de tout tester manuellement.

Executing tests once or twice a release seems efficient—fewer CPU cycles are wasted—but much will have changed and therefore many fail and cause a large batch of maintenance work. Alternatively, exe- cuting tests frequently—using a continuous integration system— uses more CPU cycles but results in less maintenance work since the effort to fix failing tests is small and straightforward. If you have a high test-maintenance load, chances are you are not executing the tests frequently enough.

Exécuter les tests une ou deux fois par livraison peut sembler efficace — car il y a moins de cycles CPU utilisés — mais entre deux livraisons beaucoup de choses auront changé, et par conséquent beaucoup de tests échoueront, ce qui aura pour conséquence de générer un gros travail de maintenance. Alternativement, exécuter les tests fréquemment — en utilisant un système d’intégration continu — utilisera davantage de cycles CPU mais il y aura moins de maintenance étant donné que la charge de correction des tests sera moindre. Si vous avez une forte charge de maintenance de tests, c’est probablement que vous ne les exécutez pas assez fréquemment.

Traitez les tests non fonctionnels comme des tests fonctionnels

Automating and continuously running non-functional tests is essential. Delaying them to the end means moving one of the biggest risks to where they hurt most. For example, if the system needs a certain performance level, test early to reach it early, and continuously run the test while new functionality is added to ensure that the system does not regress from its performance target.

Automatiser et exécuter de manière continue les tests non fonctionnels est quelque chose d’essentiel. Les retarder jusqu’au dernier moment signifie c’est prendre de très gros risques là où ça peut faire le plus mal. Par exemple, s’il est exigé que le système doit avoir un certain niveau de performance, il est nécessaire de le tester le plus tôt possible pour déterminer s’il atteint le niveau exigé, et de le tester de manière continue au fur et à mesure que de nouvelles fonctionnalités sont ajoutées pour s’assurer que le système ne régresse pas par rapport au niveau de performance exigé.

Non-functionals are often treated exotically—people believe they cannot be specified and cannot be tested. This is unfortunate. In a requirements workshop, non-functionals can be considered the same as functionals, and example tests are created for clarifying them.

Les exigences non fonctionnelles sont souvent traitées de manière assez exotique - les gens croient qu’ils ne peuvent être ni spécifiés ni testés. C’est dramatique. Dans un atelier d’exigences, les exigences non fonctionnelles sont considérées de la même manière que les tests fonctionnels, et des tests d’exemples sont créés pour aider à la compréhension.

Exécuter de manière continue des tests qui prennent du temps à s’exécuter

Non-functional tests frequently cannot be run in the normal continuous-integration-system cycle because they may take too long to execute—a stability test might take two weeks. Some product groups delay them until near the release—creating a delayed feed-back cycle. Not a good idea.

Il est fréquent que les tests non fonctionnels ne puissent s’exécuter dans un cycle normal d’intégration continue parce qu’ils prennent trop de temps à s’exécuter - un test de stabilité peut prendre jusqu’à deux semaines. Certains groupes produits les retardent pour ainsi dire juste avant la livraison — créant ainsi un cycle de boucle de rétroaction à retardement. Ce n’est pas une bonne idée de procéder de cette manière.

Run the long-running tests all the time in a slower continuous-integration-system cycle. Treat them as any other tests. When they fail, inform all people who checked in code. After they pass, get the latest build and immediately run them again. This way the feedback cycle is as short as it can be.

Exécutez plutôt les tests qui prennent du temps de manière continue dans un cycle d’intégration continue plus lent. Traitez-les comme n’importe quel autre test. Lorsqu’ils échouent, informez les personnes ayant implémenté le code. Après qu’ils aient fait le nécessaire, récupérez le dernier exécutable et exécutez à nouveau les tests.

Utilisation de la virtualisatoin ou des conteneurs

In order to speed up the tests and keep the investment in hardware low, maximize the use of virtualization using VirtualBox or VMWare. An alternative to virtual machines (which aren’t always fast to build and easy to maintain) are linux virtual containers such as Docker

Afin d’accélérer les tests et de maintenir l’investissement matériel à un niveau raisonnable, maximiser l’utilisation de la virtualisation en utilisant VirtualBox](https://www.virtualbox.org/) ou VMWare. Une alternative à l’utilisation d’une machine virtuelle (qui n’est pas toujours très rapide à mettre en place ou à maintenir) est l’utilisation d’un conteneur virtuel linux tel que Docker.

Éviter d’utiliser des outils de tests commerciaux

We once coached at a company building a commercial “automated testing” tool—a GUI testing tool. The requested coaching? To learn how to do automated testing for developing their automated testing tool…

Une fois nous avons accompagné une entreprise qui développait un outil commercial d’ « automatisation de tests » - et pour être plus précis un outil de test IHM. Quel avait été l’accompagnement demandé ? D’apprendre comment faire des tests automatisés pour l’aider à développer son outil de tests automatisés …

A gazillion commercial test tools are available. We rarely meet people who are actually satisfied with any of them. Most are overly complex and focus more on reporting and ‘management’ than on robust test automation. Favor free and open-source tools—made by developers solving real problems—over commercial tools.

Une multitude d’outils commerciaux de tests existent. Nous avons rarement rencontré des gens qui en aient été réellement satisfaits. La plupart d’entre eux sont bien trop complexes, se focalisent davantage sur la production de tableaux de bord et la gestion plutôt que sur une automatisation robuste et satisfaisante des tests. Privilégiez plutôt les outils libres et dont le code source est ouvert, faits par des développeurs pour résoudre de vrais problèmes - plutôt que des outils commerciaux.

Example of common test automation tools:

Voici une liste d’outils d’automatisation de tests communément utilisés :

• RobotFramework
• Cucumber
• Fitnesse
• Selenium
• Capybara

There are much more. The above is just a list of common tools, but new tools pop up all the time.

Il en existe bien plus encore. La liste ci-dessus porte uniquement sur les outils les plus répandus, de nouveaux outils voient le jour régulièrement.