Organisation d’un projet de Test

Une méthodologie matérialisée par une organisation de projet

Le premier rôle d’une équipe de test est de placer, sur le chemin critique du projet, les phases de test adéquates et d’en définir précisément le contenu et l’organisation.

1. les tests fonctionnels MOE vérifient la conformité des composants réalisés à leurs spécifications,
2. les tests d’intégration applicative vérifient la conformité des échanges entre composants internes à l’application,
3. les tests fonctionnels MOA vérifient la conformité de chaque fonctionnalité à ses exigences fonctionnelles,
4. les tests d’intégration système vérifient laconformité des échanges entre l’application et le reste du SI, voir les services extérieurs à l’entreprise (partenaires et clients),
5. les tests de processus (UAT) vérifient la cohérence fonctionnelle d’ensemble,
6. les tests non-fonctionnels vérifient la conformité aux exigences non fonctionnelles.

Certaines exigences non-fonctionnelles, telles que l’ergonomie ou l’adéquation à une charte graphique, pourront être vérifiées lors des tests fonctionnels. D’autres, telles les performances ou la sécurité, seront plutôt vérifiées à un niveau global. Selon l’application, les différentes phases n’auront pas le même poids dans l’ensemble du projet.

L’étape de préparation élabore un cadrage précis et détaillé du projet de test

Englobant la revue des exigences et de la conception, destinées à affiner et affermir la trame même de l’application à produire, cette étape s’appuie sur ces deux sources pour procéder à l’analyse du risque logiciel, puis élaborer ses deux livrables que sont la stratégie de test et le protocole de recette.

Le protocole de recette définit l’organisation et les moyens de chaque phase identifiée par la stratégie: rôles & responsabilités, environnements techniques, outillage, budget, planning. Au niveau global du projet de test, il fournit la consolidation du budget et du planning, il définit les règles retenues pour la gestion des anomalies, ainsi que l’outillage associé, les mesures de suivi de la couverture testée, de la qualité et de l’avancement du projet, ainsi que l’outillage pour effectuer ce suivi.

Chaque phase de test est une succession de quatre étapes…

Bien tester un composant, une fonctionnalité ou un processus nécessite de disposer d’un ensemble de scénarios de test, formalisés à l’avance, de façon précise et détaillée et hiérarchisés selon des priorités précises. Ils constituent le plan de test de la phase concernée. Dans la majorité des cas, les scénarios s’appuient sur des jeux de données dont la définition et les valeurs doivent être déterminés à l’avance. Ce travail est le but de l’étape de Conception (étape 2).

Un plan de test n’est pas suffisant pour autant. L’exécution des tests nécessite aussi un environnement technique spécifique, distinct du contexte de développement et pourvu de l’ensemble des composants et outils nécessaires, ainsi que des données pertinentes. De plus, on doit s’assurer de la disponibilité de tous les éléments permettant de garder une trace des tests effectués, de leur résultat, des anomalies détectées et de leur résolution. Enfin, on devra être en mesure de suivre l’avancement des tests et la qualité des composants testés. Si la plupart de ces éléments sont largement définis dans le protocole de recette, leur mise à disposition pour une phase de test donnée, est le but de l’étape d’Initialisation (étape 3) .

C’est seulement une fois que ces deux premières étapes sont achevées que peut débuter l’étape d’exécution (étape 4), au cours de laquelle les testeurs exécutent les tests prévus selon le plan, enregistrent le résultat des tests, signalent les anomalies détectées, procèdent au test des anomalies corrigées et enregistrent les mesures d’avancement et de qualité.

Dans le cas où les tests portent sur une nouvelle version d’une application existante, l’exécution doit faire passer en premier le test de la conformité des évolutions et corrections, en second le test de non-régression des parties non modifiées.

L’étape d’exécution prend fin lorsque les critères d’arrêt des tests, déterminés dans la stratégie de test, sont atteints.

Après la fin de l’étape d’exécution, l’étape de bilan (étape 5) a pour but d’élaborer un rapport de test sur lequel s’appuiera la décision de passer ou non à la phase suivante, en fonction du niveau de qualité attesté par le résultat des tests et argumenté par les mesures de qualité et de couverture, ainsi que par le bilan des anomalies détectées.

…qui ne figurent pas toutes sur le chemin critique du projet

Cette organisation en 4 étapes se répète pour chaque phase de test déterminée par la stratégie de test. Seules les deux dernières étapes (exécution et bilan) sont sur le chemin critique du projet. Les étapes préparatoires de conception et d’initialisation se déroulent en parallèle du projet de réalisation.

De plus, il est important de noter que les livrables des étapes de conception et d’initialisation, créés lors de la première version de l’application, seront largement réutilisables pour le test des versions suivantes. En particulier, le plan de test devra simplement être amendé pour les parties ajoutées ou modifiées et pourra servir tel quel pour tester le périmètre de régression potentielle.

Un projet parallélisé maximise le planning, sécurise les échéances…

Concevoir un plan de test, quelle que soit la phase concernée, est envisageable dès lors que l’on dispose de l’expression des exigences, de la conception applicative qui en découle et de la stratégie de test. De même, la disponibilité du protocole de recette permet de mettre en chantier l’étape d’initialisation de toute phase de test.

Seules les étapes d’exécution des tests et de bilan nécessitent la disponibilité des composants pour être mises en œuvre. Pour cette raison, ce sont, pour chaque phase de test, les seules étapes à figurer sur le chemin critique du projet.

Dès lors, dès la fin de l’étape de préparation du projet de test, il est possible de lancer les différentes phases de test, comme autant de sous-projets parallèles et indépendants les uns des autres, du moins dans les deux étapes préparatoires.

Avec un impact réduit sur le chemin critique, chaque phase peut être planifiée en fonction de ses besoins propres, notamment pour la conception du plan de test, des jeux de données associés et la préparation de l’environnement.

Bien évidemment, la qualité des composants réalisés ne saurait être garantie a priori, sinon pourquoi tester ? Une qualité insuffisante peut induire des besoins de correction immédiate des anomalies et de test de ces corrections, entraînant l’allongement de l’étape d’exécution.

Ce risque projet doit être pris en compte dans la planification de la phase, mais il est diminué par l’analyse de risque qui permet d’orienter les priorités de test vers les éléments les plus critiques de l’application. Si le planning l’impose, on pourra alors être en mesure d’accepter la présence d’anomalies jugées mineures, car porteuses d’un risque négligeable.

… et favorise le recours aux compétences les mieux adaptées

Une gestion indépendante des phases de test assouplit les conditions d’affectation des compétences.

Celles qui portent sur des problématiques techniques seront confiées à des intervenants rattachées à la MOE. Pour autant, on évitera de confier le test d’un composant aux personnes en charge de sa réalisation, afin d’éviter un effet de « partialité naturelle » pouvant conduire à des tests moins efficients en terme de couverture et de pertinence.

Les phases portant sur les aspects métier de l’application pourront être confiées à des profils MOA, maîtrisant le métier et destinés à utiliser l’application. Outre l’apport d’une vision métier à la pertinence et à la couverture des tests, ce principe permet une meilleure appropriation par les utilisateurs d’une application destinée à être utilisée régulièrement par la suite.