Réponse

Historique de la question :

À mesure que la complexité des logiciels augmente, il a été constaté qu'une partie des bugs n'est découverte qu'en dehors des cas de test ou des spécifications — souvent, ces bugs sont les plus critiques pour les utilisateurs réels. Pour trouver de tels défauts, les testeurs utilisent des techniques spéciales, combinant des tests standard avec leur propre expérience.

Problème :

Les bugs cachés, liés à l'interaction entre composants, à un traitement incorrect de situations non évidentes ou à l'absence d'exigences, sont les plus difficiles à détecter et à documenter. Souvent, les testeurs ne sont pas sûrs s'il faut formaliser le problème trouvé, s'il "n'est pas inscrit dans le cahier des charges".

Solution :

Ils utilisent des méthodes de test exploratoire, de test en binôme, et s'appuient sur leur expérience avec des produits similaires. Documentez toujours ce type de bug de la manière la plus détaillée possible : étapes, observations, pourquoi vous pensez qu'il s'agit d'un défaut, liens vers des exigences connexes ou la logique acceptée.

Caractéristiques clés :

Nécessité d'initiative et de pensée critique.
Il est important d'argumenter pourquoi il s'agit bien d'un défaut.
Dans certains cas, il faut participer à la discussion avec des analystes/PO.

Questions pièges.

Peut-on ne pas documenter ou ignorer des bugs non décrits dans les exigences ?

Non, signalez-les toujours, même s'il n'y a pas de lien précis avec une exigence, sinon des problèmes critiques toucheront le client.

Un inconfort utilisateur est-il un bug ou une amélioration (demande de fonctionnalité) ?

Si le comportement est clairement illogique, cause de la confusion ou des risques, documentez-le comme un bug, sinon, comme une amélioration.

Le testeur doit-il consulter l'équipe pour chaque bug non évident ?

Il est conseillé de discuter au préalable du cas litigieux avec un analyste ou un développeur, afin d'éviter des tickets sans fondement.

Erreurs typiques et anti-patterns

Ignorer les défauts évidents pour les utilisateurs qui ne sont pas documentés dans les exigences.
Documentation faible/incomplète des bugs cachés.
Absence d'argumentation pour le rapport de bug.

Exemple tiré de la vie

Cas négatif

Le testeur a remarqué qu'en ouvrant simultanément deux fenêtres, le système se bloque, mais n'a pas créé de bug car ce scénario n'était pas décrit dans les exigences et les cases de test.

Avantages :

N'a pas ajouté un bug "superflu", a libéré les mains des développeurs pour d'autres tâches.

Inconvénients :

Le système est sorti en production avec une vulnérabilité critique, les clients ont été touchés.

Cas positif

Le testeur a documenté le bug avec une description de l'étape (ouverture de deux fenêtres, séquence des actions), a joint une capture d'écran, a expliqué pourquoi il considérait cela comme un bug (un utilisateur réel pourrait se retrouver dans cette situation).