Testing exploratoire : le guide pour Product Owners

Ce qu'est (et n'est pas) le testing exploratoire#

Le testing exploratoire n'est pas du test aléatoire. C'est une démarche structurée où le testeur conçoit, exécute et apprend en même temps, guidé par un charter et un timebox.

Il ne remplace pas les tests scriptés ou automatisés : il les complète en attaquant les zones que personne n'a pensé à couvrir.

Rédiger un charter en 3 lignes#

• Cible — quelle feature, quel parcours, quel composant.
• Angle — quel risque explorer (perf, données, permissions, edge-cases).
• Sortie attendue — ce que vous voulez avoir compris ou trouvé.

Le déroulé type d'une session de 60 minutes#

• 5 min — relire le charter et préparer les données de test.
• 40 min — explorer, annoter, capturer sans s'arrêter pour rédiger.
• 10 min — trier les observations en bugs, questions, améliorations.
• 5 min — publier les tickets et partager un mini-débrief.

Ce qu'il faut capturer à la volée#

L'ennemi numéro un du testing exploratoire, c'est la reconstitution a posteriori. Notez toujours : URL, viewport, action effectuée, résultat observé, ressenti.

« Si vous devez rejouer le bug pour le décrire, vous avez déjà perdu 30 minutes. »