Dans les grandes pratiques du Test, deux méthodologies coexistent : la méthode exploratoire et la méthode scénarisée. Si vous avez les moyens, le temps, les ressources et les compétences disponibles, il est conseillé d'opérer les deux méthodes. Mais les conditions sont rarement toutes réunies, alors il faut faire des choix.
Penchons-nous sur la méthode exploratoire pour bien mesurer ses avantages et ses inconvénients.
Comme son nom l'indique, le test exploratoire explore le produit, sous toutes ses coutures fonctionnelles, graphiques et ergonomiques. Sans plan de test préalable, elle oblige à mener de front toutes les activités liées au test : la découverte du produit, son fonctionnement, la compréhension de sa conception, et donc des cas de tests susceptibles de révéler des défauts, l'exécution des tests et la détection des bugs.
Pour opérer les tests exploratoires, il est indispensable que le testeur/explorateur ait une expérience approfondie de la chasse aux bugs. Polyvalent, aventurier et créatif, il doit être autonome car il travaille souvent seul sur une campagne en exploratoire, celle-ci étant sans cadre ! Muni de sa "caisse à outils", c'est-à-dire son expérience, sa réussite réside dans sa capacité à comprendre et analyser le produit et deviner où les risques (bugs) peuvent se cacher.
Lorsqu'il y a peu de spécifications fonctionelles disponibles, ou quand celles-ci évoluent en permanence par exemple pour le développement en méthode agile.
Lorsque vous êtes en béta test, avant de débuter un processus de test structuré.
Lorsque vous manquez de temps.
Lorsque le produit est peu complexe.
Lorsque vous êtes à la recherche d'un bug particulier dont vous souhaitez mesurer les risques, et ainsi définir des tests scénarisés.
Lorsque vous souhaitez diversifier votre approche du test.
Lorsque vous souhaitez avoir une objectivité des tests, une véritable indépendance, neutralité.
Malgré la notion d'exploration, il faut tout de même cadrer les tests exploratoires, c'est-à-dire définir le périmètre de test, définir des limites. Pour cela, il suffit de répondre à quelques questions simples :
Ce n'est pas parce qu'on explore un produit qu'on ne doit pas s'astreindre à reporter les bugs, ni à définir les cas de test; simplement ceux-ci sont définis au fils de l'eau. Aussi, les cas de test sont reportés, définis, illustrés, évalués.
Pour plus de détails sur les test logiciels, n'hésitez pas à consulter notre site ou à télécharger notre livre blanc.