💥 Accédez en illimité à
tous nos livres & vidéos, sur l'IA, le dev, les réseaux... Cliquez ici
-100€ sur l'abonnement annuel à
la Bibliothèque Numérique ENI. Cliquez ici

Stratégie de test en milieu agile

Définition

Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts.

G. Myers (The Art of Software testing)

Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus.

Standard Glossary of Software Engineering Terminology

L’erreur est humaine et notre monde matériel est soumis à l’usure, donc, nous ne pouvons échapper à l’erreur puisque tout système qui vieillit finit par être défaillant. Quand une erreur se produit, qu’elle soit humaine ou matérielle, l’état du système en erreur devient invalide, nous constatons alors un défaut, une anomalie dans le système ; il y a alors une différence entre le comportement attendu et le comportement observé et tout système en défaut va obligatoirement induire une défaillance, la conséquence de l’erreur. Suivant la gravité de l’erreur de départ, la défaillance du système sera plus ou moins catastrophique. Il existe des systèmes où la moindre erreur est inacceptable soit...

Les différents types de tests

L’agilité n’a pas vraiment révolutionné la stratégie de test. Les tests sont, comme hier et aujourd’hui, le procédé de vérification et de validation de la qualité logicielle. Si on veut un produit de qualité, il faut le tester avant livraison !

Ce qui a vraiment changé avec les méthodes agiles, c’est que l’on teste certainement plut tôt et beaucoup plus qu’avant et cela est dû au mécanisme des sprints. Si à la fin d’un sprint on doit livrer un bout de produit fonctionnel, ce bout de produit doit tout de même être livré avec toute la qualité exigée. Autrement dit, des tests nécessaires ont forcément été réalisés durant le sprint.

L’agilité nous a appris à décomposer les besoins business en User Story (US), ainsi, par exemple, d’un cahier des charges de 200 pages pour une solution à livrer autrefois, on est passé aujourd’hui, en mode agile, à des centaines et centaines d’US à livrer pour cette même solution. Disons que pour chaque sprint, nous sommes conduits à développer 15 US, pour chacune de ces 15 US que l’on développera durant un sprint, il faudra prévoir les tests nécessaires pour assurer la qualité de livraison. En agile, on livre petit à petit en testant systématiquement au fur et à mesure alors qu’avant, on pouvait développer son code et s’occuper de le tester plus tard, bien plus tard !

Maintenant, un problème se pose : durant un sprint, on ne peut pas tout tester, et le problème n’est pas nouveau, même autrefois, en cycle V par exemple, on ne pouvait pas tout tester d’un coup.

images/01-05DP01.png

Dans un cycle en V, les différentes étapes du cycle de développement sont réalisées de façon séquentielle, de l’analyse des besoins jusqu’à la recette qui est l’étape finale pour valider toute la solution commandée.

Dans cette méthode traditionnelle de développement, comme l’indique le schéma ci-dessus, la séquence des événements est donc la suivante : Exigences (analyses...

Que dit l’agilité sur les tests ?

Les activités de tests devraient commencer aussi tôt que possible dans le cycle de développement du logiciel et devraient être focalisés vers des objectifs définis.

Nous avons vu que dans le cycle V, les tests sont effectués différemment dans des contextes différents de façon séquentielle. En agilité, dans un sprint, on doit faire tous les tests possibles, que ce soient des tests en mode boîte noire ou boîte blanche. En agilité, ce qui va vraiment changer, c’est que l’on va compacter dans un sprint tous les tests possibles. Mais comme notre solution est livrée progressivement, petit bout par petit bout, on ne va pas tout tester dans un sprint ! Si par exemple dans un projet de réseau ferroviaire, nous n’avons pas encore créé les classes métiers qui parlent de signalisation, aucune chance de tester si un train qui circule sur une voie respecte bien la signalisation ! Par contre, comme à notre niveau de développement, nous savons dans notre simulateur faire circuler un train sur plusieurs voies, nous aurons déjà fait tous les tests possibles concernant la circulation du train sur les voies. Par exemple est-ce que le train prend la bonne voie quand nous changeons l’aiguillage ? Est-ce que le train déraille bien quand il prend une courbe à une vitesse trop excessive ? Il ne faudra pas attendre que tout le système soit développé pour commencer à faire ces tests !...