Par définition, les tests exploratoires sont toujours des tests différents, conçus et exécutés simultanément. Si l'on s'en tient à cette définition, leur automatisation peut sembler peu naturelle. Et pourtant, la mise en place d'une automatisation basée sur des combinaisons de scénarios prédéfinis et aléatoires pourrait avoir un intérêt : la découverte de bugs métier.
Tests exploratoires : tests de logiciels "métier" de haut niveau
Le principe des tests exploratoires est simple, mais il nécessite un environnement calme et du temps à disposition : un utilisateur, qui est généralement un expert métier dans le domaine mis en œuvre par le logiciel, décide d'explorer une partie du logiciel en réalisant un scénario métier complet qu'il juge pertinent.
Dans la typologie des tests logiciels, les tests exploratoires sont souvent associés aux tests fonctionnels car ils constituent une famille de tests logiciels qualifiés de tests " métier " de haut niveau : leur objectif est de vérifier la capacité du logiciel à réaliser les procédures complètes pour lesquelles il a été conçu. Ces procédures peuvent impliquer plusieurs entités organisationnelles de l'entreprise, plusieurs systèmes d'information et divers processus, d'où l'intérêt de tester des scénarios que les tests de validation n'abordent pas nécessairement.
En termes d'organisation, avoir une politique de tests exploratoires est très bénéfique : l'équipe de validation est une mine d'informations et de connaissances, et les faire travailler sur des scénarios de haut niveau leur permet de traiter un cas client propice aux idées nouvelles : évolution des fonctions, de l'interface utilisateur.
Automatisation des tests métier de haut niveau
Dans certains cas, l'automatisation des tests métier de haut niveau est assez complexe : la combinaison de différentes fonctions mises en œuvre peut générer des multitudes de cas, tous complémentaires, et tous ayant la possibilité d'être reproduits par un utilisateur final.
En outre, la multiplication des environnements d'exécution pourrait imposer la possibilité de reproduire ces scénarios sur des plateformes différentes, mais mettant en œuvre les mêmes fonctions.
Pour surmonter ces deux difficultés, nous avons basé notre solution Agilitest sur deux piliers très importants : la possibilité de réaliser des tests multicanaux et la possibilité de varier les tests, notamment par l'utilisation de fichiers CSV ou JSON. Ces deux seules capacités nous permettent de remédier à ce problème, en permettant de rejouer le même test sur plusieurs environnements ou en gérant la complexité combinatoire des tests à travers des fichiers de données.
Les tests exploratoires : le moyen de découvrir les bugs métier
Malheureusement, les tests exploratoires sont souvent mal mis en œuvre dans les tests de logiciels car les équipes n'ont pas assez de temps, pourtant ils sont très importants et complémentaires aux tests fonctionnels.
Dans certains cas, ils conduisent même à la découverte de bugs fonctionnels : problèmes d'affichage, problèmes de données, fonctions bloquées, etc.
Dans d'autres cas, il est également possible de réussir à réaliser un scénario qui est impossible dans la réalité, ou à l'inverse, de ne pas réussir à reproduire un scénario qui devrait être possible.
Dans ce cas, nous avons trouvé ce que nous pouvons appeler un "bug métier".
Que faire face à des bugs métier ?
Face à des bugs métier, il y a deux possibilités :
- Le logiciel n'est pas conforme à ce qui a été spécifié, nous avons un bug qui se reproduit dans des conditions particulières qui ne sont pas celles testées dans nos plans, qu'ils soient manuels ou automatisés.
- Le logiciel est conforme à ce qui a été spécifié, mais correspond à une combinatoire qui n'a pas été définie : il est toujours très difficile de spécifier toutes les possibilités fonctionnelles d'un logiciel, et nous sommes tombés dans une zone grise. Les testeurs qui connaissent bien le métier sous-jacent savent définir le comportement attendu de l'application, qui n'est pas celui qu'ils viennent d'observer. Cela pose la question de faire travailler les équipes de test très tôt dans le processus de développement, directement avec les architectes fonctionnels, les product owners, etc. pour éviter que cette situation ne se reproduise ; et c'est généralement une bonne pratique, car elle peut éviter des développements non désirés.
Dans les deux cas, la correction du bug combinée à la production d'un nouveau cas de test vous permettra d'enrichir vos plans, de clarifier le comportement attendu de l'application, et de confirmer l'équipe de validation dans la capacité de l'outil testé à réaliser un scénario plus complexe.
Qu'en est-il de l'automatisation des tests ?
Chez Agilitest, ce que nous recommandons est la correction des bugs métier en ajoutant des contrôles lors de la réalisation des différentes fonctions.
Nous proposons également de réaliser un test automatisé qui reproduit ce bug métier et contrôle le fait qu'il ne se reproduira pas. C'est le cœur de ce que peut faire Agilitest : gérer la complexité et la combinatoire en utilisant des sous-scripts exécutant des fonctions de haut niveau et des fichiers de données pour varier complètement les scénarios rejoués.
D'une manière générale, il est important de toujours couvrir les corrections de bugs par des tests de non-régression automatisés liés aux bugs, afin de s'assurer qu'elles ne peuvent pas se reproduire : il est très pénible pour un client qui a signalé un bug dans la version N de le voir corrigé dans la version N+1, puis réapparaître dans la version N+2.
En conclusion, lorsqu'un test exploratoire conduit à la découverte de bugs métier, il est utile d'automatiser le scénario afin de l'ajouter à la batterie de tests fonctionnels. Et si l'automatisation d'un test exploratoire peut sembler trop complexe en raison de la nature combinatoire du test, rappelez-vous qu'Agilitest a été conçu pour gérer cette complexité.
.png)
