Le cycle de développement de l'activité de tests orientés objet

by Scott W. Ambler, traduction en français par Guillaume Goarnisson, UNILOG Lyon, France, Ingénieur Nouvelles Technologies de l'Information

Scott W. Ambler + Associates
Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map
Recently reviewed Le cycle de développement de l'activité de tests orientés objet (en anglais, "Full-Lifecycle Object-Oriented Testing" - FLOOT) est un ensemble de techniques de tests pour vérifier et valider le logiciel orienté objet. Le cycle de vie FLOOT qui est décrit dans la Figure 1, indique qu'une large variété de techniques de tests (voir le Tableau 1 ) couvrant tous les aspects du développement logiciel sont à votre disposition. La liste proposée ne cherche pas à être exhaustive, mais au contraire à rendre explicite le fait que vous disposiez d'un large choix de techniques de tests. Il est important de comprendre que "la méthode" FLOOT est présentée ici comme un ensemble de phases périodiques (ou successives) mais que ce n'est pas forcément toujours le cas. Les techniques du FLOOT peuvent aussi bien être appliquées aux processus agiles. Je présente le FLOOT de manière traditionnelle pour bien faire passer le message que les tests doivent être menés tout au long du développement logiciel et non pas seulement lors des tâches de codage.

Figure 1. Le cycle de vie FLOOT.

Tableau 1. Les techniques de tests

Technique FLOOT

Description

Test boîte noire

Test qui permet de s'assurer que l'unité qui est testée fournit, à partir de paramètres d'entrées conforme, le résultat attendu.

Test aux limites

Test sur des valeurs inhabituelles, particulières ou limites que le système doit pouvoir gérer.

Test de classe

Tâche qui permet de s'assurer qu'une classe et ses instances (objets) fonctionnent comme défini.

Test d'intégration des classes

Tâche qui permet de s'assurer qu'une classe et ses instances (objets) issus de logiciels externes fonctionnent comme défini.

Revue de code

Revue technique qui consiste en une révision du code source : vérification de la conformité du code par rapport aux normes de programmation et aux spécifications.

Test de composant

Tâche de validation du bon fonctionnement d'un composant.

Couverture de test

La tâche qui consiste à s'assurer que chacune des lignes de code a été testée.

Revue de conception

Revue technique qui consiste à explorer le modèle de conception.

Test de non-régression avec l'héritage

Tâche permettant de s'assurer que les cas de tests fonctionnent sur la classe "mère" et les classes "filles" ("mère" et "fille" : notions entre les classes introduites avec l'héritage).

Test d'intégration

Test pour vérifier que des lots fonctionnels fonctionnent correctement ensemble.

Test de méthode

Test pour vérifier que des méthodes (ou opérations) fonctionnent comme défini.

Revue de modèle

La revue de modèle consiste à explorer complètement le modèle. La revue est d'autant plus pertinente qu'elle est réalisée par des personnes qui n'ont pas participé à la mise en oeuvre de ce modèle.

Test des chemins logiques

Tâche permettant de s'assurer que tous les chemins possibles ont été testés au moins une fois (Le composant est considéré comme un ensemble de branches constituant des chemins possibles qui doivent tous être vérifiés).

Revue de prototype (ou Test de prototype)

Pour cette revue, les futurs utilisateurs utilisent aux travers d'une collection de cas d'utilisation (c'est à dire diverse manière d'utiliser le système) le prototype comme ils utiliseraient la future application. L'objectif principal est de s'assurer que le prototype répond bien aux attentes des utilisateurs.

Preuve par le code

Le meilleur moyen de s'assurer que le modèle correspond au besoin ou bien encore à ce qui doit être construit est de produire le logiciel basé sur ce modèle. Ceci permettra de valider l'exactitude du modèle.

Test de non-régression

Tâche permettant de s'assurer que les précédents "modules" testés fonctionnent encore après des modifications apportées à l'application.

Test de stress (voir aussi Test de charge)

Tâche permettant de s'assurer que le système supporte les gros volumes de transactions, de charge, d'utilisateurs... (supporte dans le sens de fonctionner correctement).

Revue technique

Technique d'assurance qualité qui consiste à faire examiner et critiquer la conception de l'application par des pairs. La revue typique se concentre sur la qualité, la facilité d'utilisation, la cohérence, la couverture. On peut également parler de "Revue par ses pairs".

Test de scénarios d'usage (ou de scénarios de cas d'utilisation)

Technique de test dans laquelle un ou des membres de l'équipe projet valide le modèle "en déroulant" des scénarios de cas d'utilisation du système.

Test de l'interface utilisateur (Test UI)

Les tests concernant l'interface utilisateur permettent de vérifier le respect des standards d'interface (standard UI) et de s'assurer que l'on répond aux exigences définies au cours du projet concernant l'interface.

Test boîte blanche (ou Test boîte de cristal)

Test qui permet une validation technique du composant testé. (Remarque : Ces tests complètent les tests boîtes noires et permettent de détecter les parties de code non accessibles et les comportements indésirables.).

J'aimerais un peu partager l'idée que je me fais de l'activité de tests :

  1. L'objectif est de trouver des défauts (des anomalies). L'intérêt premier des tests est de valider le bon fonctionnement (l'exactitude) de tout ce que l'on peut tester. En d'autres termes, des tests concluant décèlent des anomalies..
  2. Tous les artefacts peuvent être validés. Comme indiqué dans ce document, vous pouvez tester tous vos artefacts et non pas uniquement votre code source. Vous pouvez tout au moins réviser les modèles et documents et ainsi détecter et corriger des anomalies bien avant qu'elles ne se retrouvent dans le code.
  3. Tester souvent et le plus tôt possible. Le coût lié aux changements qui croît de façon exponentielle en fonction de l'instant de découverte du défaut (ou d'un changement nécessaire) devrait vous motiver à tester au plus tôt dans le projet. (Voir article concernant le coût lié au changement : cost of change)
  4. Tester procure de la confiance, de l'assurance. Dans Extreme Programming Explained Kent Beck propose une observation intéressante : quand vous avez une suite complète de tests, suite de tests dans le sens collecion de tests, et que vous les exécutez aussi souvent que possible, cela vous donne du courage pour aller de l'avant. Beaucoup de personnes craignent de faire un cahngement dans leur code sous peine de casser ce code. Mais avec une suite complète de tests, si vous veniez à casser quelque chose, vous savez que vous le détecteriez et que vous pourriez le résoudre.
  5. Tester suivant la criticité de l'artefact. Plus un élément est risqué, plus il a besoin d'être révisé et testé. En d'autres termes, vous devez investir un effort certain pour examiner et tester un système de contrôle du trafic aérien et aucun effort pour une application du type "Hello World".
  6. Un test vaut plus que mille paroles. Vous aurez beau me dire que votre application fonctionne, tant que vous ne m'aurez pas montré les résultats des tests, je ne vous croirais pas.

Suggested Reading

Disciplined Agile Delivery This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

Traductions:


Disciplined Agile Delivery: The Foundation for Scaling Agile Agile Modeling: Practices for Scaling Agile Agile Data: Practices for Scaling Agile EnterpriseUP: Agility at Scale AgileUP: Towards Disciplined Agile DeliveryAmbysoft Inc. Software Development Practices Advisor Scott Ambler + Associates Follow @scottwambler on Twitter!


Copyright 2004-2012 Scott W. Ambler

This site owned by Ambysoft Inc.