Combien de fois ai-je entendu « on n’a pas pu passer les tests, on n’a pas les données » ?
Les causes sont nombreuses : des plateformes de test dont l’intégrité des données n’est pas managée, des données trop anciennes qui ne respectent plus les règles, des données trop fraîches (dump de Prod) que personne de connaît….
N’oublions pas que le RGPD nous impose des règles très strictes lorsque l’on utilise des données de personnes.
L’article de Jean Chambard établi une très bonne synthèse du sujet : Données de production ou synthétiques, comment gérer les données de test, quels sont les outils disponibles. En 5 pages, vous avez l’essentiel pour se poser les bonnes questions.
Permettez-moi d’ajouter un autre retour d’expérience sur le sujet.
J’ai vu récemment dans une très grande entreprise une situation où les données de test sont devenues un problème majeur. Dans certains cas, seul le test en production (sic) est possible, dans d’autres, il faut convoquer 5 personnes de services différents au même endroit et même moment pour dérouler les tests. Inutile de dire que le test est devenu ici un irritant de la DSI comme du métier.
Ma préconisation porte sur deux points :
- La plateforme de test est un objet à part entière, il a un propriétaire, le platform manager. Cela induit que les chefs de projets n’installent plus des patches à loisir ou ne dumpent la prod inopinément. C’est le platform manager qui organise cela et garanti l’intégrité des différents applicatifs et des données qu’ils partagent.
- Les données sont également un objet à part entière. Constituez un book de données qui référence les principaux cas fonctionnels. Vous cherchez un client avec un litige de plus de 500€ ? Vous le trouverez dans le book de données. Passez donc un peu de temps à construire en amont ce book avec les différentes parties prenantes… et vous gagnerez des journées lors de vos campagnes de test.
Les données de test sont votre cauchemar ? Dépensez un peu de temps en amont, elles pourraient devenir une solution !
