Réponse.

Cas de test — ce sont des scénarios préparés à l'avance avec des étapes clairement définies, des entrées et des résultats attendus. Les tests exploratoires (exploratory testing) sont réalisés sur le tas : le testeur génère des vérifications en apprenant le produit, en utilisant son expertise et son intuition. Historiquement, les cas de test dominaient d'abord, mais avec la complexité croissante des systèmes et l'augmentation du volume des tests manuels, les tests exploratoires ont commencé à compléter les approches formelles.

Problème

Suivre aveuglément un seul type de test limite l'ingéniosité du testeur et peut laisser le produit avec des bogues non détectés, non décrits dans les cas.

Solution

Utiliser les deux approches de manière équilibrée : les cas de test — pour les fonctionnalités de régression et critiques, les tests exploratoires — pour les sections nouvelles, encore non entièrement formalisées et en cas de délais courts.

Caractéristiques clés :

Les cas de test — garantissent la répétition et un résultat comparable
Les tests exploratoires — augmentent les chances de trouver des bogues non standards et sournois
Les deux approches doivent aller de pair

Questions pièges.

Peut-on utiliser uniquement des cas de test pour un couvert à 100 % ?

Non. Même le jeu de cas le plus détaillé ne couvre pas le comportement imprévu d'un utilisateur ou des bogues non standards.

Les tests exploratoires nécessitent-ils une préparation préalable ?

Oui. Il est nécessaire de comprendre la fonctionnalité, d’étudier les exigences, de saisir la logique commerciale avant de pouvoir explorer librement le produit.

Un rapport de bogue est-il obligatoire après les tests exploratoires ?

Oui. Tout défaut trouvé doit être documenté aussi précisément qu’un bogue d’un scénario formel, sinon il est difficile à reproduire et à corriger.

Erreurs typiques et anti-patterns

Négliger une des approches
Absence de documentation des bogues trouvés lors des tests exploratoires
Ignorer la fonctionnalité du produit avant le début de la session exploratoire

Exemple de la vie

Cas négatif

L'équipe a couvert la version uniquement avec des cas de test formels. Un testeur a suivi strictement les instructions, ne vérifiant pas les cas « connexes », ce qui a conduit à manquer un bogue apparaissant lors d'une certaine séquence d'actions, non prévue à l'avance.

Avantages :

Automatisation rapide et simple de la reporting

Inconvénients :

Profondeur de vérification insuffisante
Manque de flexibilité

Cas positif

Le testeur, après avoir passé les cas de test clés, a consacré une heure aux tests exploratoires, trouvant un bogue qui ne se reproduit que lorsque l'heure sur l'appareil est changée pendant que l'application est en cours d'exécution.