Retour sur la conférence Les tests exploratoires par Mathilde Lemée à Devoxx.
Quand il s’agit de tester nos applications, nous avons divers outils de test automatisés pour éviter les régressions. Après une modification, nous effectuons généralement manuellement un test de conformité, pour vérifier que ce que l’on obtient correspond bien à ce qui est demandé (ce qui est aussi une manière de tester les tests…). Cependant, on ne peut pas toujours tout tester, notamment au niveau des effets de bords, et il est impossible de tout couvrir par des tests automatiques, en particulier au niveau de l’imprévisible. C’est là qu’interviennent les tests exploratoires, qui sont complémentaires aux autres tests, et surviennent principalement en fin de projet.
Une phase de tests exploratoires consiste à partir à l’aventure dans l’application sans plan préétabli, afin de faire des manipulations imprévues pour découvrir des bugs. Le testeur doit penser à prendre des notes pendant tout le test, à la fois pour pouvoir reproduire les anomalies rencontrées et pour partager avec son équipe ce qui a été exploré. Pour un nouvel arrivant sur le projet, il s’agit d’un moyen très efficace de comprendre comment fonctionne le produit. Plus on fait de tests exploratoires, plus on est efficace pour trouver des bugs par ces tests. On finit par connaître les points faibles de son application.
Si l’exploration lors du test est hasardeuse, celui-ci nécessite tout de même un cadre et une préparation. Quand on part dans un test, c’est avec une idée de ce qu’on va y faire, et celle-ci se formule par une phrase de la forme suivante : Exploration d’une cible, avec une ressource, pour chercher un problème particulier. Par exemple : explorer l’édition de profil avec des attaques d’injection pour trouver des failles de sécurité. Une fois le test exploratoire défini (de préférence par quelqu’un qui n’a pas codé la fonctionnalité explorée), on ne planifie pas son exécution, les développeurs en choisiront eux-même le moment, ce qui permet d’avoir plus de créativité. De même, le test sera limité dans le temps pour ne pas lasser le testeur.
Mathilde Lemée nous a ensuite donné quelques astuces pour améliorer ses tests, ce à quoi il faut penser :
- Ne pas se contenter de regarder le résultat, mais observer également la log, l’état du CPU, de la mémoire ;
- Faire bouger les valeurs des variables, ne pas oublier de tester avec 0, 1, trop ou trop peu ;
- Voir ce qui se passe quand un fichier est corrompu, que le disque est plein ;
- Endosser un personnage : le cliqueur frénétique, le maniaque des onglets, l’aficionado des boutons avant/arrière du navigateur…
- Tester avec plusieurs états du téléphone, appuyer sur les boutons n’importe comment ;
- Utiliser des jeux de tests différents de ceux utilisés précédemment ou pour les tests unitaires.
Certains tests sont difficiles à contrôler, quand les résultats sont probabilistes et non déterministes (cache, machine learning). Dans ce cas, nous pouvons au moins tester ce qui doit toujours se passer, ainsi que ce qui ne doit jamais se produire. De même, on peut chercher si les résultats donnés sont dans un intervalle cohérent, à défaut d’être certain de leur justesse. On peut également faire un nombre très important de tests et vérifier que la répartition des résultats est normale.
La grosse difficulté de ces tests est de convaincre les décideurs de l’importance d’y accorder du temps. Pourtant, certains bugs sont vicieux et il est impossible de les débusquer par des procédures classiques. Il va de soit que quand un bug est trouvé par les tests exploratoires, il faut écrire le test unitaire correspondant.
Crédit photo
