Gérer les données : la principale contrainte

Définir des jeux d’essai pertinents

Le chapitre précédent nous a permis de dégager les informations suivantes :

De la partie produit, nous déduisons alors différents périmètres de tests obtenus par un rapprochement et une priorisation des risques et exigences produit : des plans de test.

Cette approche constitue le point de départ de la construction du périmètre des données nécessaires aux tests, que cela soit pour les tests unitaires, une recette technique ou une recette fonctionnelle.

Mais avant d’entrer dans le vif du sujet, il convient de définir ce que l’on entend par l’expression "jeu d’essai" car un test est tributaire de différents types de données :

Les données en environnement dégradé

La présente section concernera davantage les recettes techniques en sortie de développement. La raison à cela est relativement évidente : les environnements de tests métier sont la plupart du temps sans dégradation.

Mais c’est ici une règle très générale que nous supposons et des exceptions sont bien sûr possibles.

Qu’appelle-t-on environnement dégradé ?

Nous avons partiellement évoqué ce sujet dans le chapitre précédent. Il s’agit ici de comprendre qu’un environnement de recette ne dispose pas nécessairement de toutes les données, de tous les traitements non plus, notamment les jobs automatiques de nuit. C’est le cas fréquemment de solution exploitant des gros systèmes (mainframe) pour lesquels l’accès aux données n’est pas possible.

Mais ce peut être aussi au cours d’un programme ou tout simplement de deux projets liés (voire le lotissement du projet lui-même s’il y en a un), une contrainte de planning qui amène l’absence d’un traitement.

Cette incomplétude technique des données, tant en accès qu’en transformation, est ce que nous appelons une dégradation d’environnement.