Découvrir un produit sans spécifications grâce au Test Exploratoire : vers un plan de test structuré
Je vous propose une série d’articles sur le test exploratoire.
Cette série d’articles explore en 5 parties les thèmes suivant :
- Explication du test exploratoire,
- Un guide des heuristiques pour mieux maitriser le test exploratoire,
- Comment utiliser le test exploratoire pour définir son plan de test pour un produit sans spécification (cet article) ?
- Comment effecteur du test exploratoire sur des APIs ?
- Comment automatiser nos tests exploratoires ?
Tester l’inconnu, une opportunité pour le Test Exploratoire
Lorsqu’un produit ou une fonctionnalité est livré sans spécifications détaillées, cela peut sembler une tâche intimidante pour les testeurs. Pourtant, c'est une occasion idéale pour appliquer le test exploratoire. Cette approche permet de comprendre rapidement le produit, d’identifier les zones critiques et de construire un plan de test efficace basé sur l’apprentissage direct.
Pour guider cette exploration, les heuristiques offrent des cadres pratiques pour structurer et prioriser les efforts. Voici comment utiliser les bonnes heuristiques au bon moment pour découvrir un produit inconnu et définir un plan de test pertinent.
Étape 1 : Plonger dans le produit avec curiosité
Le test exploratoire repose sur la découverte progressive. L’heuristique SFDIPOT (Structure, Fonction, Données, Interfaces, Plateformes, Opérations, Temps) est idéale pour structurer cette étape. Pour commencer :
- Explorez l’interface utilisateur (UI)
- Notez les éléments disponibles : menus, boutons, champs, messages d’erreur.
- Interagissez comme un utilisateur final, en suivant un flux logique.
- Interprétez les comportements
- Quels sont les résultats attendus d’une action (ex. : cliquer sur un bouton) ?
- Que se passe-t-il si vous déviez des chemins évidents (ex. : soumettre un formulaire vide) ?
- Identifiez des patterns fonctionnels
- Les fonctionnalités se ressemblent-elles dans leur comportement ?
- Y a-t-il des incohérences dans l’interface ou les flux ?
Exemple pratique : Vous testez une application de gestion de tâches. Commencez par cartographier les composants principaux (Structure), testez la création/modification/suppression de tâches (Fonction), et explorez la gestion des délais ou rappels (Temps).
Étape 2 : Formuler des hypothèses et tester les limites
Une fois les bases explorées, il est temps d’approfondir les scénarios critiques et les cas limites. L’heuristique FEW HICCUPPS (Focus, Énergie, Windows, History, Inconsistencies, Compatibility, Claims, User Scenarios, Problems, Performances, Support) est parfaite pour cela.
Après une première phase de découverte :
- Formulez des hypothèses
- "Si je remplis ce champ avec une valeur invalide, je devrais recevoir un message d’erreur."
- "Ce bouton devrait rediriger vers une autre page."
- Testez les cas extrêmes et inattendus
- Essayez des valeurs limites, comme des chaînes très longues ou des caractères spéciaux.
- Introduisez des scénarios inhabituels, comme une déconnexion en plein processus.
- Évaluez la robustesse
- Le produit gère-t-il bien les erreurs ?
- Les comportements sont-ils cohérents à travers différentes parties de l'application ?
Exemple pratique : Après avoir identifié que le produit permet d’ajouter des tâches, testez des cas comme :
- Ajouter une tâche sans titre ou avec des caractères spéciaux (Inconsistencies).
- Vérifier si la liste des tâches est compatible avec un affichage mobile (Compatibility).
- Tester un scénario où un utilisateur modifie une tâche pendant une synchronisation réseau (User Scenarios).
Étape 3 : Identifier les risques et les zones critiques
Après avoir exploré le produit avec SFDIPOT et FEW HICCUPPS, vous aurez une meilleure idée des zones critiques à approfondir. En test exploratoire, l’apprentissage vous permet rapidement de repérer des zones potentiellement problématiques :
- Fonctionnalités sensibles
- Y a-t-il des fonctionnalités essentielles pour l’utilisateur (ex. : paiement, connexion) ?
- Ces fonctionnalités nécessitent-elles des scénarios de test approfondis ?
- Comportements imprévisibles
- Les erreurs ne sont-elles pas correctement gérées ?
- Des bugs impactent-ils d'autres parties du système ?
- Dépendances technologiques
- Identifiez des intégrations avec des API ou des services tiers susceptibles d’introduire des vulnérabilités.
Exemple pratique :
- Si un module de paiement est présent, il doit être priorisé en raison de son impact direct sur les revenus.
- Si l’application utilise une API tierce pour synchroniser des données, testez les comportements en cas de panne ou de réponse lente de l’API.
Étape 4 : Documenter et construire un plan de test
À mesure que vous découvrez le produit, commencez à formaliser un plan de test basé sur vos observations :
- Listez les fonctionnalités
- Identifiez les modules ou fonctionnalités clés à tester.
- Classez-les par priorité (haute, moyenne, basse) en fonction des risques identifiés.
- Définissez des scénarios de test
- Créez des cas de test simples pour chaque fonctionnalité explorée.
- Ajoutez des scénarios pour les cas limites et les données invalides.
- Ajoutez des tests non-fonctionnels
- Performance : Le produit est-il rapide et réactif ?
- Sécurité : Les données sensibles sont-elles protégées ?
- Compatibilité : Fonctionne-t-il sur différents appareils ou navigateurs ?
- Documentez vos découvertes
- Utilisez des outils comme des feuilles Excel, des mind maps ou des outils de gestion de test (ex. : TestRail, Xray) pour centraliser vos observations.
- Notez les zones non couvertes pour des tests ultérieurs.
Étape 5 : Impliquer l’équipe et itérer
Le test exploratoire est collaboratif. Une fois votre plan de test initial défini :
- Partagez vos découvertes
- Organisez une session de debriefing avec les développeurs, les chefs de projet et les parties prenantes.
- Validez vos hypothèses et identifiez des zones critiques supplémentaires à tester.
- Affinez le plan de test
- Intégrez les retours pour prioriser les efforts de test.
- Ajoutez des cas de test manquants basés sur la vision partagée de l’équipe.
- Automatisez où c’est pertinent
- Si certaines fonctionnalités sont stables et répétitives, envisagez l’automatisation pour réduire les efforts futurs.
Exemple pratique
Vous testez une application de gestion de tâches sans spécifications :
- Vous commencez par explorer l’ajout, la modification et la suppression de tâches.
- Vous testez des scénarios comme :
- Ajouter une tâche sans titre.
- Supprimer une tâche déjà supprimée.
- Modifier une tâche en cours d’enregistrement.
- Vous découvrez que l’API retourne des erreurs 500 pour des requêtes invalides.
- Vous formalisez un plan de test couvrant les actions de l’utilisateur, les cas limites et les intégrations API.
De l’exploration au plan d’action
Le test exploratoire transforme une situation incertaine – un produit sans spécifications – en une opportunité de découverte approfondie et de construction structurée. En combinant curiosité, heuristiques et documentation rigoureuse, vous pouvez non seulement comprendre rapidement le produit, mais aussi livrer un plan de test ciblé et efficace.