Réponse.

Historique de la question :

Le problème de la suffisance des tests est apparu lorsque les projets sont devenus grands et que le temps est devenu limité. Il est devenu nécessaire de comprendre qu'il était temps d'arrêter les tests pour utiliser efficacement les ressources. Le testeur doit expliquer au business que les tests réalisés sont « suffisants » et que les risques sont minimaux.

Problème :

Il est impossible d'atteindre une couverture parfaite avec des tests manuels — il y a toujours des limites de temps et de ressources. Une couverture insuffisante conduit à des défauts manqués, tandis qu'une couverture excessive entraîne un dépassement de budget et des retards.

Solution :

Utiliser des métriques de couverture : pourcentage des exigences passées, couverture du code (s'il y a accès), ratio des scénarios uniques/modules.
Mettre en œuvre des pratiques de matrice de traçabilité pour aligner les tests aux exigences.
Organiser des revues collaboratives des cas de tests et des défauts avec l'équipe.

Caractéristiques clés :

Harmonisation entre les exigences, les cas de tests et les modules fonctionnels.
Évaluation des risques pour définir des priorités.
Capacité à justifier clairement pourquoi les tests sont terminés.

Questions piégées.

Peut-on se baser uniquement sur la couverture par les cas de tests sans prendre en compte les risques ?

Non. Il est nécessaire de tenir compte des priorités fonctionnelles : quelles sont les zones les plus critiques pour le business.

Le nombre de cas de tests indique-t-il toujours la qualité de la couverture ?

Non. Un grand nombre de cas de tests non justifiés ou en double n'est pas un signe d'une couverture élevée.

Faut-il inclure les tests exploratoires dans la métrique de couverture ?

Oui, absolument. Les tests exploratoires révèlent des défauts inattendus que les cas de tests formels n'ont pas identifiés, et ils doivent faire partie de l'ensemble de la couverture.

Erreurs typiques et anti-modèles

Se concentrer uniquement sur des indicateurs formels, en ignorant des zones de risque importantes.
Cacher les faiblesses de la couverture (exigences non prises en compte, scénarios non testés).
Dépasser les délais à cause du désir de "tout couvrir".

Exemple de la vie réelle

Cas négatif

Le testeur considère la couverture uniquement en fonction du nombre de cas de tests sans tenir compte de la zone d'impact des bugs ou des scénarios utilisateur.

Avantages :

Facilité à présenter des rapports attrayants.

Inconvénients :

Des bugs critiques peuvent rester hors de vue.

Cas positif

Le testeur, en collaboration avec un analyste, clarifie les risques, ajuste la couverture et concentre les efforts sur les composants les plus importants.