Les environnements de test

Introduction

Les tests (de tous les niveaux) sur une application sont très rarement (dans l’idéal jamais) effectués directement sur l’environnement de production. Si une nouvelle version de l’application mail que j’utilise est en développement, je ne veux pas être forcé à utiliser cette version dont la qualité est inconnue au détriment de mon ancienne version qui fonctionne très bien et dont je suis justement satisfait de la qualité !

Pour éviter ce genre de problème les entreprises utilisent des environnements de test. D’après la définition ISTQB, un environnement de test c’est « un environnement contenant du matériel, des instruments, des simulateurs, des outils logiciels et d‘autres éléments de support nécessaires à l‘exécution d‘un test », en clair c’est ce qui permet de tester l’application sans avoir à impacter le client.

Pourquoi avoir un environnement de test ?

Il y a plusieurs réponses à cette question, voici celles que je trouve les plus pertinentes :

·        Ne pas impacter les utilisateurs avec une application à la qualité douteuse. Une baisse de qualité est souvent très préjudiciable pour une application. « Mon navigateur web fonctionnait parfaitement avant mais maintenant il crash tout le temps et a des problèmes d’affichage ! Je désinstalle et en installe un autre ».

·        Avoir de la flexibilité, je peux plus facilement enchaîner des livraisons et donc des indisponibilités de mon application sur un environnement de test qu’en production. Je peux comprendre une mise à jour des serveurs de mon application mail et donc une indisponibilité pendant 1 ou 2 heures de temps en temps mais pas tous les jours.

·        Tester l’application dans des conditions spécifiques, exemple pour une application d’achat en ligne, tester le comportement de l’application lors d’un incident sur le paiement.

·        Avoir la maîtrise des données : en effet en production les données évoluent tout le temps et tout utilisateur peut les faire évoluer.

Un environnement de test doit être le plus proche possible de la production

Un environnement de test doit permettre de se mettre dans des conditions réelles. Cela ne sert à rien d’avoir tous les tests en succès si au final le comportement en test n’est pas le même qu’en production.

Un environnement de test doit être stable

Ceci est malheureusement un problème récurrent des environnements de test. Ces environnements nécessitent souvent la présence de plusieurs acteurs. Pour une application mail il faut l’application, les serveurs de stockage, le service push, le service d’authentification… Pour l’ensemble de ces acteurs ce sont des environnements de test (aussi appelé environnements de recette) et donc moins important que la production. C’est pourquoi il arrive souvent que ces environnements ne soient pas stables et cela coûte malheureusement beaucoup d’argent. En effet, avec un environnement non stable on se retrouve souvent bloqués dans nos campagnes de test, ou on perd du temps dans l’analyse des cas puis leur ré-exécution s’ils sont en échec à cause de cette instabilité.  J’ai déjà perdu 3 jours de test sur une semaine. En étant 2 testeurs à plein temps sur le projet le coût de cette instabilité a donc été de 6 jours de travail. L’accumulation de ces périodes d’instabilité sur l’ensemble d’un projet peut vite coûter très cher (dans mon exemple si on considère 1 jour de travail correspond à 400€, alors on a perdu 2 400€ sur le projet).

Un environnement de test doit être flexible

Un environnement de test doit permettre de tester l’application dans la plupart des situations prévues. Pour cela des options doivent être activables afin de mettre l’environnement dans l’état voulu. Pour reprendre l’exemple de paiement KO, un environnement de test doit être capable de le simuler. Il doit également, toujours pour le paiement et si l’application est censée le gérer, pouvoir accepter ou non certains moyens de paiement.

Les livraisons doivent être fréquentes et aisées

Un environnement de test est par définition un environnement qui est en mouvement. On teste une fonctionnalité et on trouve un bug ou une régression de l’application. Après que le développeur ait corrigé ce bug il doit être dans la capacité de livrer rapidement sur cet environnement une version avec la correction de ce bug. De même Si une fonctionnalité est livrée un jour puis qu’une autre est prêtre à être livrée le lendemain on doit pouvoir tester cette nouvelle fonctionnalité sur l’environnement de test rapidement. On ne doit pas perdre de temps en attendant des livraisons, l’environnement de test n’est pas la production. Il ne faut pas que lors de la phase de test les personnes travaillant sur cet environnement se retrouvent à attendre la prochaine livraison.

Les données doivent être gérées

Les données sont un problème récurrent lors des phases de tests. Prenons l’exemple d’un cas de test avec une application mail. On envoie un mail dont le titre « test 1 » sur l’adresse mail de test. Le test consiste alors à ouvrir l’application sur l’adresse mail et vérifier que le premier mail de la liste a bien pour titre « test 1 ».

Dans certains cas, si les données sont mal gérées (ex : un autre test envoie un autre mail titré « Pièce Jointe ») et les tests tournés en parallèle (automatiquement sur plusieurs machines ou manuellement par plusieurs testeurs)  alors « test 1 » peut ne plus être le premier mail de la liste et le test est donc en échec (dans cet exemple le cas est en échec s’il est automatisé, manuellement le testeur comprendra certainement la situation et mettra le test en succès).

Une mauvaise gestion des données est facteur de perte de temps et de fiabilité des tests.

Conclusion

Les environnements de tests sont nécessaires à tout développement de logiciel. Ils permettent de tester le produit avant sa mise sur le marché sans risque pour la production. Néanmoins pour qu’il soit vraiment efficace il ne faut pas qu’il soit un frein au développement mais aussi qu’il soit fiable. C’est pourquoi il faut faire particulièrement attention à ces environnements. La qualité finale du produit dépend grandement de la qualité des environnements de test.

Glossaire ISTQB : http://swisstestingboard.org/wp-content/uploads/2014/04/Glossaire_des_tests_de_logiciel_-_2_1_F_ISTQB.pdf