« LeSS - Automatisation des tests » : différence entre les versions

De Wiki Agile
← Modification précédente
VisuelWikicode
 
(18 versions intermédiaires par le même utilisateur non affichées)
Ligne 52 : Ligne 52 :
Vue globale du test exploratoire :
Vue globale du test exploratoire :


[[Fichier:LeSS-Et-fr.png|800px|sans_cadre|centré|Tests exploratoires]]
[[Fichier:LeSS-Et-fr.png|800px|sans_cadre|centré|Tests exploratoires|link=]]


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é » – [http://www.satisfice.com/articles/what_is_et.shtml Bach03(vo)]. 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 :
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é » – [http://www.satisfice.com/articles/what_is_et.shtml Bach03(vo)]. 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 :
Ligne 60 : Ligne 60 :
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 toutes les heuristiques traditionnelles de tests sont utilisées lors de cette phase de conception.
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 toutes les heuristiques traditionnelles de tests sont utilisées lors de cette phase de conception.


[[Fichier:Less Et scripted difference-fr.png|800px|sans_cadre|centré|Tests exploratoires]]
[[Fichier:Less Et scripted difference-fr.png|800px|sans_cadre|centré|Tests exploratoires|link=]]


== Test automatisé ==
== Tests automatisés ==


=== Créer des tests maintenables ===
=== Créer des tests maintenables ===
Ligne 81 : Ligne 81 :


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.
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.
=== Delete tests when not adding value ===


=== Supprimer des tests lorsqu’ils n’apportent aucune valeur ===
=== 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.
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.
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.
=== Avoid testing through the UI ===


=== Éviter de tester à travers une IHM ===
=== É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.
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.
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.
=== Run tests frequently ===


=== Exécuter les tests fréquemment ===
=== 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.
 
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.


=== Treat non-functionals the same as functionals ===
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 continue — 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 ===
=== Traiter 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é.
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’elles ne peuvent être ni spécifiées ni testées. 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.
 
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.
 
=== Continuously run long-running tests ===


=== Exécuter de manière continue des tests qui prennent du temps à s’exécuter ===
=== 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.
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.
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.


=== Use virtualization or containers ===
=== Utiliser la virtualisation ou les conteneurs ===
 
=== 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 [https://www.virtualbox.org/ VirtualBox] or [http://www.vmware.com/ VMWare]. An alternative to virtual machines (which aren’t always fast to build and easy to maintain) are linux virtual containers such as [http://www.docker.io/ 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 [https://www.virtualbox.org/ VirtualBox] ou [http://www.vmware.com/ 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 [http://www.docker.io/ 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 [http://www.vmware.com/ 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 [http://www.docker.io/ Docker].
 
=== Avoid using commercial test tools ===


=== Éviter d’utiliser des outils de tests commerciaux ===
=== É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...
 
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.
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 :
Voici une liste d’outils d’automatisation de tests communément utilisés :
 
* [http://www.robotframework.org/ Robot Framework]
* [http://www.robotframework.org/ RobotFramework]
* [https://cucumber.io/ Cucumber]
* [https://cucumber.io/ Cucumber]
* [http://www.fitnesse.org/ Fitnesse]
* [http://www.fitnesse.org/ FitNesse]
* [http://www.seleniumhq.org/ Selenium]
* [http://www.seleniumhq.org/ Selenium]
* [https://github.com/jnicklas/capybara Capybara]
* [https://github.com/jnicklas/capybara 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.
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.
Récupérée de "https://wikiagile.coach/LeSS_-_Automatisation_des_tests"