Tests exploratoires, le « nouvel » outil indispensable ?

Introduction

On parle de plus en plus des tests exploratoires comme étant une solution indispensable. Je fais d’ailleurs également parti des personnes poussant pour les mettre en place et pars du principe qu’il est contre productif, particulièrement avec les méthodes incrémentales, d’écrire des tests qui ne seront exécutés qu’une seule fois.

Partant de ce constat je pousse pour mettre en place ces tests.

Définition rapide

Mais, les tests exploratoire c’est quoi exactement ?

J’avais écrit un article il y a longtemps à ce sujet. Pour être honnête je le trouve bien mais incomplet. Si vous voulez avoir une description plus à jour et complète je ne peux que vous conseiller la conférence de Frédéric Assante Di Capillo de la STLS 2018.

Pour résumé, les tests exploratoires c’est:

• faire la conception et l’exécution des tests en même temps
• des tests toujours différents
• des tests ciblés avec un objectifs
• des tests qui dépendent du testeur
• des tests documentés (la partie qui manquait dans mon premier article)

Pourquoi les mettre en place ?

La problématique de temps est prépondérante avec les méthodes de développement incrémentales (souvent Agiles) et les testeurs (ou plutôt les équipes) doivent faire face à plusieurs contraintes qui semblent opposées:

• Un time to market très faible
• Une qualité au niveau

Le premier point pousse à diminuer le temps attribué aux tests. On pense alors généralement à:

• l’automatisation pour diminuer le temps d’exécution
• la sélection des tests pour diminuer le nombre de test
• La parallélisation des tests
• L’ATDD ou le BDD pour avoir moins de maintenance

Tout ceci est très bien mais, dans les faits on ne travaille que sur les tests de régression qui, au final, sont souvent devenus peu optimisables (ou alors pour un coût trop important).

Le second point pousse à augmenter le nombre de tests et leur couverture!

Cela est également très bien mais plus de test veut dire plus de temps de conception, d’écriture, d’exécution de maintenance et d’analyse!

En fait il existe un moyen de concilier gain de temps et gain en qualité!

Ce moyen c’est les tests exploratoires.

On pense (trop) rarement à optimiser le temps passé sur des tests qui peuvent être particulièrement chronophage, des tests qui ne sont pourtant exécutés qu’une seule fois et qui peuvent s’avérer peu pertinents au cours de la campagne à laquelle ils appartiennent. Je pense bien sûr aux « tests de validation » qui ont pour but de valider le fonctionnement d’une nouvelle fonctionnalité.

Le temps passé à l’écriture de ces tests peut être particulièrement important. J’ai connu des équipes où l’écriture et élaboration de ces tests pouvait prendre la moitié du temps des testeurs!

La mise en place des tests exploratoires permet de diminuer fortement le temps alloué à l’écriture et la conception des tests mais permet également de faire plus de tests, mieux ciblés. Le testeur peut alors adapter la campagne aux défauts rencontrés et donc appliquer le principe du regroupement de défauts!

Il faut néanmoins faire attention, les tests exploratoires c’est bien si c’est mis correctement en place! Et ce, même si l’on n’écrit plus les tests! Il faut réussir à avoir de l’information avec ces campagnes!

Comment les mettre en place

Pour mettre en place les tests exploratoires il faut tout d’abord les « institutionnaliser » et faire reconnaitre leur valeur.

Ce n’est pas parce que l’on n’est pas capable de reproduire exactement un scénario de test que ce dernier n’a pas de valeur! Cela peut sembler une évidence mais c’est une reproche fréquent fait aux tests exploratoires.

De mon point de vue, dans ce cas on se retrouve sur une dérive où le but des tests est plus de montrer que l’on a fait du travail plutôt que procurer l’information nécessaire sur le niveau de qualité de l’application.

En fait, cela revient à mettre au dessus « Des processus et des outils plutôt que les individus et leur interactions » soit l’opposé du manifeste Agile.

Pour institutionnaliser les tests exploratoires il faut:

• L’ajouter à sa stratégie de test
• Prévoir du temps pour ces tests exploratoires à travers des sessions dédiées
• Donner un but et un objectifs à ces sessions
• Avoir des preuves et un historique de l’exécution des tests

Le premier point est assez simple à mettre en place mais dans cette optique il faut également expliquer comment on résout l’ensemble des points suivants.

Pour répondre aux 3 points suivants il existe un outil fantastique! Cet outil c’est les charte de test exploratoire.

Voici à quoi peut ressembler une charte basique:

Comme on peut le voir, cette charte permet de connaitre les résultats de la campagne et conjugue Bilan ainsi que des informations habituellement contenues dans un ALM (HP ALM, Testlink, Refestest, XStudio…) en donnant ces informations:

• Qui a exécuté les tests
• Quels tests ont été exécutés (avec ici uniquement l’essence du test: son but ou objectif)
• Quelles anomalies ont été trouvées
• Combien de temps a duré la campagne (définit en amont)
• Quel était le but de la campagne (définit en amont, cela peut être couvrir un risque (ex: régression induite par la nouvelle fonctionnalité), une fonctionnalité (envoi de PJs) ou tout autre objectif)

Cette charte qui est archivée après la campagne permet d’obtenir l’information que l’on attend des tests de validation mais aussi de garder des preuves de test ce qui pourra toujours servir pour identifier de potentielles régressions.

Attention, les tests exploratoires ne sont pas auto-suffisants!

Les tests exploratoires sont un complément! Pour chaque nouvelle fonctionnalité implémentée il doit y avoir au moins un test de régression. Les tests de régression ne peuvent pas être constitués de tests exploratoires.

Les tests qui sont voués à être ré-exécutés doivent être écrits!

Pourquoi est-ce si important ? (problématiques de temps, efficience des tests, rend visible « l’invisible »)

Mettre en place les tests exploratoires peut sembler être quelque chose qui peut être repoussé à plus tard néanmoins ces campagnes de tests sont particulièrement importantes pour plusieurs raisons:

• Elles font gagner un temps précieux qui peut être ré-alloué d’autres tâches avec de plus fortes valeurs ajoutées ou simplement gagner du temps sur le développement des fonctionnalités
• Elles sont peu coûteuses à mettre en place (retour sur investissement très rapide et élevé)
• Elles rendent le métier de testeur plus intéressant en limitant un maximum les tâches peu efficiente (vous avez dit Lean ?)
• Elles permettent l’exécution d’un plus grand nombre de test. Il est toujours plus rapide de faire un test directement plutôt que lire chaque étape et faire les vérifications manuellement.
• Elles permettent d’avoir des campagnes de test plus pertinentes car offrent la possibilité d’adapter ses recherches en fonction de ce qui est trouvé (comme pour une chasse aux champignons)
• Elles rendent visible l’invisible. Soyons honnête, la pratique des tests exploratoires est très répandues bien que non officialisée. Malheureusement le fait que les tests exploratoires ne soit pas bien considérés fait qu’il n’y a pas (ou peu) de charte de test et finalement seul celui qui a fait ses tests connait, pour une durée plus ou moins courte, le résultat de ses tests.

Conclusion

Si vous ne faites pas encore de tests exploratoires il est temps de commencer! Les tests exploratoires sont un outil formidable à condition qu’ils soient bien mis en place. Ils permettent de gagner en temps et en qualité et pas seulement avec les méthodes incrémentales. Il est parfaitement possible (et je le recommande) de proposer des campagnes hybride de validation avec des applications développées avec des cycles en V. cela permet d’allier la rigueur des campagnes de test prédéfinies (car on a le temps de bien les préparer avec ces méthodes de développement) avec la flexibilité des tests exploratoires.

Il faut cependant garder à l’esprit que les tests exploratoires seuls ne sont pas suffisant. cela reste un complément à l’ensemble des outils déjà à disposition des testeurs. Pour les méthodes de développement incrémentales, selon moi, l’idéal est d’écrire uniquement les tests de régression, de les automatiser et de faire l’ensemble des tests de validation avec des tests exploratoires après avoir fait une analyse du besoin et des risques liées à la fonctionnalité ajoutée.

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.