Principaux concepts et cycle projet

1. Introduction

a. Premières considérations : parlons la même langue !

Nous partirons du principe que le lecteur est totalement novice en matière de production logicielle afin de définir les mots employés et exposer un vocabulaire qui devrait idéalement être commun à tous les professionnels du monde de l’informatique.

Malheureusement, l’expérience montre que derrière les mots se cachent des concepts qui n’ont pas toujours la même compréhension. Il y a une part de méconnaissance ou plus exactement de connaissances orientées par une expérience professionnelle propre, qui fait que certains concepts organisationnels sont compris sous un angle qui différera d’un lecteur à l’autre.

Mais il y a aussi une part d’interrogation soulevée par les mots eux-mêmes dont les définitions peuvent être tributaires d’un contexte. Hors de ce contexte, le mot employé perd alors son sens.

Un simple exemple pour illustrer ceci : l’expression "test d’intégration" fait référence à des tests permettant de vérifier une interopérabilité entre deux logiciels ou deux composants d’un même logiciel. Mais lorsqu’un environnement de test est appelé "environnement d’intégration", par extension, un test réalisé dans cet environnement pourra être improprement appelé test d’intégration sous ce seul prétexte.

Et de cette considération générale, nous pouvons même plus précisément affirmer que le vocabulaire et les abus de langage sont l’une des principales problématiques de l’univers du test.

Le présent chapitre est donc indispensable : il est le prérequis incontournable auquel les professionnels sont confrontés pour parler un vocabulaire commun.

b. Schéma général du cycle projet

Le schéma suivant représente les étapes principales d’un cycle projet conduisant à la réalisation d’un logiciel puis sa maintenance dans un contexte industrialisé. Le principe qu’il expose est relativement classique dans le monde industriel si ce n’est une spécificité...

Types de test

1. Pendant le projet

a. Relecture des spécifications

Qu’il soit de release ou de maintenance, un projet passe par une étape de conception qui débouche sur un livrable : les spécifications. Une première technique de test est incontestablement leur relecture. Peut-être serez-vous surpris de lire ce commentaire ici, mais l’expérience montre que très souvent ses dernières sont lues "en diagonale".

Nous conseillons expressément de ne pas tomber dans ce travers. Que la recette à organiser soit technique ou fonctionnelle, que vous deviez mettre en place des tests unitaires, peu importe, lisez !

Avantageusement, une lecture en binôme permettra de remonter un maximum d’observations. Focalisez-vous notamment à rechercher ce qui est absent, les trous fonctionnels, les non-dits. Et ces derniers peuvent être nombreux. Quelques exemples :

Sur la description des données

Si un champ est indiqué comme alphanumérique, faire préciser son format exact : alphabétique, avec ou sans caractère accentué, en majuscule, en minuscule. Faire préciser aussi sa longueur, si les espaces à gauche et à droite sont acceptés, etc.
Si un champ est numérique, faire préciser son domaine de validité avec précision (signé ? non signé ? nul ? usage du point ou de la virgule pour les réels ? quel séparateur pour les milliers ?).
Si un champ est une date, faire préciser son domaine de validité, notamment par rapport à la date du jour. Impérativement, faire préciser comment est définie la date du jour (lue sur le serveur applicatif ? sur le serveur de données ? sur le PC client ? …).

Sur la description des traitements

Pour les lectures en base de données, le résultat doit-il être trié ? Quelles sont les conversions de format utilisées une fois les données lues ?
Pour les écritures en base de données, quelles sont les données faisant l’objet d’une contrainte d’unicité ? Quelles sont les conversions de format utilisées pour le stockage de l’information ?
Pour les suppressions en base de données, quel pourrait être le rythme de ces dernières : ponctuelles...

Contextes de mise en œuvre des tests

Nous évoquerons sommairement les contextes organisationnels des principes évoqués dans la section précédente.

Car si les tests peuvent être organisés en différents points du cycle projet, les objectifs ne sont pas les mêmes à chaque fois et les stratégies diffèrent selon l’organisation.

1. Côté maîtrise d’œuvre

a. Maîtrise d’œuvre externe

Une société qui souhaite développer une solution pourra faire appel à un prestataire de services externe pour réaliser un développement. Dans cette situation, la MOA de l’entreprise fait appel à sa DSI pour un projet et il est convenu que la solution consistera à trouver les ressources en dehors de cette dernière pour des raisons de savoir-faire ou budgétaires.

Les décideurs du projet devront alors se poser de sérieuses questions sur le choix du prestataire, et notamment vérifier si ce dernier dispose d’une cellule de qualification technique qui homologue sa production logicielle de manière plus ou moins indépendante de la MOE.

Deux cas sont possibles alors :

Si le prestataire externe dispose d’une cellule de tests techniques, la MOA pourra avoir une relative confiance dans la qualité des livrables et n’aura pas nécessité à renforcer son propre effort de test en recette métier.
Si le prestataire externe ne dispose pas d’une cellule de tests techniques, la MOA devra peut-être faire appel à une cellule d’experts en tests techniques en interne ou en externe chez un autre prestataire....