Qui ne s’est jamais posé la question ou a eu un débat sur le choix de tester avec des jeux de données de production ou des jeux de données construits ?

Jeux de données de production

Les jeux de données de production sont issus d’une extraction à un instant T des données en production. Cette extraction est faite à la taille d’une application (cette information est importante pour la suite) et en général sur une sous partie des données de production, la globalité ne pouvant pas forcément être chargée sur des environnements de test avec des dimensionnements différents.

Cette solution nécessite donc un outil pour extraire et recharger les données (au sens large du terme : paramétrage, utilisateurs…), ainsi qu’un paramétrage particulier et souvent compliqué dans certains cas, quand on veut extraire un sous périmètre des données de production.

Une fois cette extraction réalisée, il faut alors chercher la donnée nécessaire aux tests. Donc soit on utilise les écrans pour les trouver, soit on fabrique des requêtes en base de données pour les identifier.

Si on veut faire du test à l’échelle du SI, il faut arriver à synchroniser l’extraction des données de production de l’ensemble des applications à une date précise, potentiellement gérée par des équipes et sur des technologies différentes…

Et bien entendu il faut anonymiser les données. Ce qui peut poser problème dans certains cas, quand les données sont centrales pour le fonctionnement, tel qu’un numéro de sécurité sociale.

Jeux de données construits

Le workflow est plus court dans ce cas, car il s’agit « seulement » de créer les données dans les applications en utilisant les écrans ou les traitements le permettant. Le seul entrant dans ce cas est donc la connaissance des actes de gestion pour pouvoir créer les données, si possible suivant une logique d’acte de gestion de production.

Par contre cette création, sauf solution d’automatisation, est faite un par un, ce qui engendre des coûts différents en fonction de la taille des jeux de données nécessaires.

Comparatifs

Comme on a pu le voir il est parfois compliqué d’obtenir un jeu de données de production. De plus, je pense que c’est arrivé à beaucoup d’entre nous, même quand on l’obtient on n’est jamais réellement sûr qu’il corresponde à notre cas, qu’il n’a pas un historique particulier, issu d’une migration, … qui en fait correspondrait à des cas d’utilisations marginaux ou différent de celui recherché.

D’un autre côté les jeux de données construits sont maitrisés. Et si ils sont fait sur la base des procédures du métier, sont d’égale qualité. Par contre, chaque jeu de données supplémentaires construit à un coût.

Et le sujet est là, d’un côté on a une solution monolithique et parfois complexe, et de l’autre une solution sur mesure avec un coût progressif. D’expérience la solution de jeu de données construit est souvent la moins chère, par contre une étude est rarement réalisée, et le coût de la solution production est souvent dilué sur plusieurs équipes, outils… ce qui le rend plus indolore pour les équipes qualité, mais pas pour l’entreprise.

Il faut aussi avoir à l’esprit que pour une nouvelle application il n’y a pas de données de production. Donc si on prend le sujet depuis le début on construit les données. Par contre il faut les maintenir, ce qui est à mettre au regard de la fréquence des extractions de production pour avoir toujours des données « fraiches ».

Pour finir il faut donc choisir la meilleure solution par rapport au contexte et problématiques. Souvent quand on a besoin de grosse volumétrie (performance, test d’entrepôt de données …), une complexité ou un temps de création important, on préférera les données de production. Et de manière générale dans les autres cas les données construites.

Donc pas de gagnant pour ce combat, match nul, à vous de faire votre choix.