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

De Wiki Agile
← Modification précédente
VisuelWikicode
 
(5 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 83 : Ligne 83 :


=== 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.
Ligne 116 : Ligne 112 :
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.


=== Utilisation de la virtualisatoin ou des conteneurs ===
=== Utiliser la virtualisation ou les conteneurs ===


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 [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].
Ligne 122 : Ligne 118 :
=== É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"