Pendant longtemps, la « chute d’eau classique » a été considérée comme le bon modèle de cycle de vie pour développer tous les systèmes. Bien que ce modèle ait de solides arguments en sa faveur, il présente aussi quelques inconvénients dans son approche linéaire d’un projet.
En réalité, les projets ne suivent jamais un flux séquentiel. Si nous analysons la manière dont toutes les activités de test se produisent dans ce modèle, nous voyons que beaucoup du planning et de la documentation survient vers la fin de chaque phase, avant la phase suivante. Par exemple, la création de plans de tests système et de cas de test se produit souvent quand la phase de développement est bien avancée. Je ne vous demande pas d’abandonner ce modèle si vous vous sentez à l’aise avec lui. Mais je recommande quelques changements qui amélioreront la qualité de votre test d’applications.
Contenu complémentaire :
Collecter les données de performance du System i avec Collection Services |
Il vaut mieux commencer certaines des tâches associées au test tôt dans le cycle de vie de développement logiciel (SDLC, software development life cycle). Bien que nous puissions suivre l’approche chute d’eau pour les phases de développement, nous devons créer en parallèle une documentation de test à l’appui.
C’est ce qu’on appelle le modèle en « V ». Quand nous commençons chaque phase à gauche du V, nous créons la documentation de test à l’appui à droite du V. Nous continuons le développement vers le bas du V, puis nous exécutons les activités de test proprement dites pour chaque phase quand nous revenons vers le haut du V à droite, et finalement nous exécutons le test d’acceptation utilisateur quand nous atteignons le sommet.
Ce faisant, nous avons transformé notre modèle chute d’eau classique d’un modèle séquentiel en un modèle où les activités parallèles accompagnent les diverses phases du projet. La figure 1 illustre cette approche. L’objectif de ces deux techniques est d’introduire de la qualité dans le produit que nous développons au fur et à mesure que nous progressons dans le SDLC. Prenons, par exemple, la construction d’exigences fonctionnelles. Les utilisateurs du système doivent songer à la manière dont ils valideront les exigences quand ils conduiront leurs tests d’acceptation utilisateur.
S’ils sont incapables de définir des cas de test pour les exigences, un problème se pose, car les exigences deviennent non quantitatives et par conséquent non mesurables. Toute méthodologie doit être non seulement adaptative mais aussi très évolutive. Il est difficile de présenter des changements radicaux dans une organisation, particulièrement là où l’équipe informatique est petite et où l’on pratique le « coder et corriger ». Les lignes directrices suivantes proposent une alternative à ce que vous pratiquez peut-être actuellement. Selon votre culture d’entreprise, vous pourrez commencer de manière plus ou moins brutale. Bien pris en mains, les utilisateurs sont généralement prêts à conduire des tests d’acceptation utilisateur fondés sur leurs exigences de gestion documentées et convenues.
Et, en la matière, les programmeurs peuvent amener les tests d’unités à un niveau raisonnable. Malheureusement, d’après mon expérience, la phase de test système s’est dégradée pour aboutir à une répétition de tests d’unités effectués au niveau intégration. Les lignes directrices suivantes vous aideront à être plus efficaces et plus concentrés dans la phase de test système du projet.
Téléchargez cette ressource
Livre blanc Sécurité et Stockage des documents
Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.
