Les données de test font partie intégrante des environnements de test et de leurs qualités dépend la qualité des résultats des tests exécutés. En effet, de mauvaises données peuvent engendrer des résultats de test erronés ou faire perdre beaucoup de temps d’analyse aux personnes travaillant sur l’analyse des bugs détectés. Quels sont les problèmes pouvant engendrer de mauvaises données de test ? Comment faire pour éviter résoudre ces problèmes et avoir des données de test de bonne qualité ? J’espère que vous aurez, au moins en partie, une idée de la réponse à ces questions après avoir lu cet article.
Les problèmes engendrant des données de test de mauvaise qualité
Les problèmes engendrant de mauvaises données de test sont multiples, en voici quatre récurrents:
– Des problèmes de couverture des données, c’est-à-dire que les données de test ne sont pas suffisantes pour mener à bien les différentes campagnes de test. Admettons que dans un de mes tests sur un site de réservation de billet d’avion je veuille prendre un billet Rio-Paris en classe business. Si dans le données de test je n’ai pas de place en business ou qu’il n’y a plus de place dans l’avion ou encore qu’il n’y a pas de vol entre Rio et Paris aux dates demandées alors le test est en échec à cause des données (dans mon exemple 3 données peuvent poser problèmes : le nombre de place en business, le nombre de place dans l’avion et les vols disponible).
– L’utilisation et la modification des données par plusieurs équipes. Je veux vérifier que s’il ne reste que 2 places dans l’avion pour mon trajet Rio-Paris alors je ne peux pas acheter 3 billets, par contre je peux en acheter 2. Malheureusement entre temps un billet en Business a été acheté sur ce même trajet, il ne reste donc qu’une place et la partie du test « je peux acheter 2 billets » est en échec. Nous avons donc un cas de test, en échec et à analyser alors que l’application en elle-même n’est pas forcément « buggée ».
– Les données ne sont pas mises à jour. Dans mes données j’ai des vols prévu du 1er octobre 2016 au 31 janvier 2017. Je ne peux donc pas faire de réservation pour dans 2 semaines le 20 janvier 2017.
– Les données ne sont pas accessibles aux équipes de test, le testeur doit alors essayer plusieurs trajets pour savoir sur lesquelles on peut voyager en classe Business ou faire une demande de création de données et attendre la création de celles-ci.
Possibles solutions pour ces problèmes
– Les problèmes de couvertures de données. Ce problème est particulièrement problématique car il fausse les résultats de test en mettant des cas de test en échec alors que la fonctionnalité n’a pas de défaut. Pour s’assurer d’une bonne couverture de données il faut tout d’abord bien comprendre quelles sont les données dont on a besoin en fonction des cas de test et ce pour tous les cas. S’assurer également d’avoir des données qui ne devraient pas être retournées dans les réponses, n’avoir que de bonnes données empêche de vérifier la remontée de mauvaise dans le cas d’une recherche (ex : pour une demande de vol Rio-Paris en business. Il y a 2 vols possible mais un seul propose des places en business, le vol sans business ne doit pas être proposé) et enfin avoir des données proches de la réalité. Des données issues de la production (une partie de ces données peut être suffisant) permettent d’avoir des scénarii plus proches de ce qui se fait en production.
– L’utilisation et la modification des données par plusieurs équipes. Dans l’idéal il faut limiter au plus une utilisation simultanée des données, que cela soit entre plusieurs équipes ou entre différents cas de tests (pour les cas de tests ce problème se pose encore plus lorsque l’on parallélise l’exécution des tests). Dans les faits cela est quasiment impossible dès lors ou le projet nécessite un grand nombre de personnes travaillant dessus. Dans ce cas, commencer par segmenter ces données en fonction des équipes peut être une solution simple et rapide à implémenter (par exemple, pour les vols au Brésil, une équipe travaille sur Rio-Paris et une autre sur Sao Paulo). Chaque équipe sachant qu’elle peut modifier les données qui lui sont « réservées » mais pas celles des autres. Une autre solution peut également être d’avoir les mêmes données au début du test et à la fin du test. Dans le cas d’une réservation de vol Rio-Paris, on fait notre réservation mais on l’annule à la fin du test (dans ce cas il faut que l’annulation soit rapidement effective).
– Les données ne sont pas mises à jour. Ce problème doit être anticipé avec un enrichissement suffisamment fréquent des données pour éviter ce problème (de préférence une partie des données de production afin d’avoir un environnement de test proche de celui de la production).
– Les données ne sont pas accessibles aux équipes de test. Ce problème n’est pas forcément solvable. Les problèmes d’accessibilité peuvent être en écriture mais aussi en lecture, dans le cas de site de vente de billet cela veut dire ne pas avoir accès à l’ensemble des vols disponible et n’avoir accès uniquement aux réponses de l’application. Dans le cas où avoir accès aux données n’est pas possible il faut mettre en place des process avec les équipes responsables de ces données afin de pouvoir faire les modifications voulues le plus rapidement.
Conclusion
Les données de test sont un composant essentiel des environnements de test. La qualité de l’application peut être fortement dégradée si les données ne sont pas de bonnes qualités. Afin d’avoir une bonne qualité de ces données il faut réfléchir en amont au besoin et anticiper les potentiels conflits. Quelles sont les données nécessaires pour les tests ? Quelles équipes vont les utiliser ? Ont-elles accès à ces données ? Les données sont-elles à jour ? Sont des questions auxquelles il faut de préférence avoir une réponse le plus tôt possible.
Documents intéressants sur la gestion des données de tests :
http://www.informationweek.com/pdf_whitepapers/approved/1345732672_back_to_basics.pdf
