La gestion des données de test dominera le monde
Situation initiale
Qui saura reconnaître les situations suivantes ?.
Tests manuels
Une nouvelle itération de tests est prévue. Pour exécuter tous les tests, j'ai besoin de configurations de données spécifiques, notamment des clients avec différents statuts (prospects, clients actifs, anciens clients, etc.). Cela déclenche la recherche (parfois longue) de données de test appropriées. L'itération de tests ne peut commencer qu'une fois ces données trouvées. L'effort requis pour trouver des données de test adéquates réduit donc le temps disponible pour les tests.
Tests automatisés
Après un nouveau déploiement, les tests de régression automatisés sont lancés. Le résultat : 20 % des tests ont échoué. Je me dis : « Mais qu'est-ce que c'est que ça ? » et je me lance dans l'analyse. Il s'avère que les tests n'ont pas pu être exécutés à cause de données de référence mal configurées ou de données manquantes (en clair : faux négatifs, faux positifs). Je regarde l'heure et je réalise que j'ai déjà passé une heure à comprendre que les données de test sont (encore une fois) responsables des échecs (soit 20 tests * 3 min d'analyse = 60 min).
Quiconque se reconnaît dans ces situations ne pourra que penser : «La gestion des données de test va dominer le monde».
Énoncé du problème
Prenons du recul et analysons les causes possibles des problèmes liés aux données de test. Je peux classer les causes d'erreurs et de problèmes que j'ai rencontrés au cours de ma carrière de testeur dans les catégories suivantes. (Remarque : cette liste n'est pas exhaustive et l'ordre n'est pas un critère de priorité ou d'importance.)
- Données productives
- Complexité des données de test requises
- Portée des données de test
- Durée de vie limitée des données de test (les données de test peuvent vieillir et être consommées)
- Les données de test dépendent de l'environnement
- La nécessité du voyage dans le temps
- exigences légales, sectorielles et internes à l'entreprise
- Fourniture de données d'essai
Examinons ces points en détail :
de tests (notamment l'automatisation des tests) à l'aide de données de production est vouée à l'échec. Les données de production ont généralement une durée de vie limitée. De plus, le RGPD interdit les tests sur des données de production. Par conséquent, les tests doivent être basés sur des données synthétiques et/ou anonymisées.
La complexité des données de test requises provient principalement de leur nécessité de reproduire au plus près l'environnement de production. Par exemple, tester une fonctionnalité de reporting ou d'historique requiert de nombreux jeux de données différents. Les reproduire avec des données de test synthétiques peut s'avérer très complexe. En revanche, vérifier une fonctionnalité de modification, comme la mise à jour d'une adresse, est plus simple à reproduire avec des données de test synthétiques. L'effort requis pour définir des données de test synthétiques de haute qualité, proches de celles de la production, ne doit pas être sous-estimé !
La quantité de données de test est généralement considérée en fonction du type de test. Par exemple, les tests de performance (tests non fonctionnels) nécessitent une grande quantité de données, mais seulement quelques configurations. Les tests de régression, quant à eux, requièrent un grand nombre de configurations différentes, bien qu'en faible quantité.
La durée de vie limitée des données de test constitue, à mon sens, l'un des principaux défis pour une automatisation des tests stable. Il ne suffit pas de créer les données de test une seule fois et de les réutiliser à chaque exécution. Ces données sont consommées lors de l'exécution des tests et/ou sont sujettes à l'obsolescence. Par exemple, si le statut d'un client dans un cas de test passe de « prospect » à « actif », ce cas de test ne peut plus être exécuté avec ce client.
Le fait que les données de test dépendent de l'environnement est explicite : il ne suffit pas de les créer une seule fois dans un seul environnement, par exemple l'environnement de validation. Les données de test doivent être créées dans tous les environnements sur lesquels les tests sont exécutés.
Le traitement temporel des données de test peut s'avérer nécessaire lorsque des fonctionnalités doivent être testées en fonction d'une date précise. Dans le secteur bancaire, il s'agirait par exemple des opérations de fin de mois ou de fin d'année.
Les spécifications relatives aux données de test, qu'elles soient légales, sectorielles ou internes à l'entreprise, sont essentielles. Les données de test doivent impérativement s'y conformer. Ceci est particulièrement important dans le cadre du RGPD. Conformément au RGPD, les données personnelles ne peuvent être utilisées qu'à des fins spécifiques. Les tests n'étant pas inclus dans cette finalité, il est interdit de réaliser des tests avec des données clients en production (sauf consentement explicite de la personne concernée). Le non-respect de ces exigences peut entraîner des amendes importantes, pouvant atteindre 20 millions d'euros, auxquelles s'ajoutent d'éventuelles demandes de dommages et intérêts.
En plus de ces points, de bonnes données de test sont inutiles si elles ne sont pas fournies dans le bon contexte, dans le bon environnement, au bon moment et avec la bonne qualité .
Risques
Si les points mentionnés ci-dessus sont respectés, rien ne s'oppose à la réussite des tests. Dans le cas contraire, des risques peuvent survenir et doivent être gérés. Ces risques peuvent être classiquement classés dans les catégories suivantes :
- Risque lié au produit
- Risque du projet
- Risque commercial
Un risque lié au produit existe, par exemple, si les données de test ne répondent pas aux exigences techniques et/ou ne couvrent pas toutes les combinaisons critiques pour l'activité. Dans ce cas, des erreurs non détectées pourraient se retrouver en production.
Un risque lié au projet survient, par exemple, si les données de test ne sont pas définies ou fournies en temps voulu. Cela entraîne des retards dans le projet.
Un risque commercial particulier réside dans le non-respect des réglementations légales et sectorielles. Comme indiqué précédemment, cela peut s'avérer coûteux et représenter un risque important pour l'entreprise.
Conclusion
Maintenant que nous comprenons les problèmes, les défis et les risques liés à l'absence de gestion des données de test, mon prochain article de blog portera sur l'élaboration d'une stratégie et d'un concept de données de test adaptés. Restez à l'écoute !.
27 mars 2020, Frédéric Hesse
Notre offre de qualité et de tests
Nous adoptons une approche globale de la qualité logicielle et, forts de nos nombreuses années d'expérience et de notre développement professionnel continu, nous vous offrons un soutien ciblé pour optimiser la valeur ajoutée de votre projet. Pour ce faire, nous nous affranchissons des contraintes des rôles traditionnels au sein d'un projet et nous concentrons sur les compétences qui contribuent à une qualité logicielle optimale à tous les niveaux.
> En savoir plus
