Editions ENI Livres | Vidéos | e-Formations
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 :
-
Pour le projet :
-
Les parties prenantes, les acteurs du projet.
-
La hiérarchie des exigences projet.
-
La matrice des risques projet, une évaluation de leur criticité par les parties prenantes et les actions palliatives associées.
-
Pour le produit, le ou les logiciels à réaliser :
-
Les parties prenantes, c’est-à-dire des catégories d’utilisateurs de la solution future.
-
La hiérarchie des exigences fonctionnelles et techniques du produit.
-
La matrice des risques produit, une estimation de leur criticité selon les catégories d’utilisateurs et le type de stratégie de test associé (tests unitaires, recette technique, recette fonctionnelle, tests de robustesse, tests de charge…).
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 paramètres de l’application, des informations relativement statiques qui en général restent fixées une fois pour toutes pour une campagne de test donnée (par exemple, le timeout session d’une application web, le mode de fonctionnement, etc.).
-
Les données devant préexister avant l’exécution des tests, le plus souvent des référentiels qui évoluent peu dans le temps (tables de référence de pays, référentiel produit, comptes utilisateur, permissions…) mais aussi des données "cœur de métier" que l’on pourra saisir par avance. Ces données seront davantage des prérequis qu’un jeu d’essai : nous considèrerons qu’elles participent à l’environnement de recette....
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.
Attention, l’absence d’un composant logiciel comme un plugin pour une application web pourra être considérée comme une dégradation d’environnement dès lors que les informations affichées ont un rôle pour l’application. En revanche, l’absence d’un Flash Media Player destiné à diffuser la publicité incluse dans un site pourra être ignorée. Il y a donc des cas pour lesquels la dégradation est ignorée car sans impact.
1. Modifier le jeu de données en cours d’exécution
a. Qu’est-ce qu’une simulation ?
Dès lors qu’un traitement de transformation ou d’import de données est absent, on appellera simulation toute action technique (manuelle ou automatique) visant à contourner ce manque "artificiellement".
Utiliser un outil d’accès à une base de données comme TOAD et exécuter une requête SQL pourront donc...
