Réponse.

La définition des limites du test (scope) est une tâche fondamentale pour le test manuel, permettant de se concentrer sur les parties les plus pertinentes et critiques de l'application.

Historique de la question

Avec le développement des projets, le volume des fonctionnalités à tester augmente, rendant impossible la couverture manuelle de tous les scénarios. Avec l'émergence de l'Agile/de la méthodologie incrémentale, le rôle de définition du scope a considérablement augmenté.

Problème

Si les limites du test sont floues, il y a un risque de :

Mener des tests inefficaces, en dépensant des ressources sur des fonctionnalités peu significatives
Manquer des bugs critiques dans des scénarios importants
Se chevaucher avec le travail d'autres testeurs, créant des duplications

Solution

Le scope des tests doit être déterminé sur la base de :

priorités commerciales, scénarios utilisateur et risques
analyse des exigences, récits utilisateurs et spécifications
consultations avec l'équipe (analystes, chefs de produit, développeurs)

Caractéristiques clés :

Concentration sur les principales fonctionnalités et zones à risque
Enregistrement/documentation explicite de la couverture dans le plan de test pour éviter les malentendus
Possibilité de réviser rapidement le scope en cas de changement des exigences

Questions piégeuses.

Faut-il toujours tester absolument tout ce qui est implémenté, même les plus petits détails ?

Non, le principe des tests est de se concentrer sur les parties prioritaires et critiques, surtout là où des erreurs sont les plus probables et où des bugs peuvent avoir un impact substantiel sur l'entreprise.

Un testeur peut-il élargir ou restreindre le scope par lui-même lorsqu'il y a de nouvelles exigences sans accord ?

Non, tout changement de scope doit être validé avec le chef de produit ou le chef d'équipe, afin d'éviter des lacunes ou des duplications de travail.

Est-il suffisant de se fier uniquement à la documentation technique pour définir le scope ?

Non, il est nécessaire de prendre en compte le contexte commercial, les véritables tâches des utilisateurs et les retours des clients.

Erreurs typiques et anti-modèles

Scope non fixé et changeante en permanence
Ignorer les priorités commerciales au profit de fonctionnalités secondaires
Absence de communication entre les membres de l'équipe lors des changements des limites du test

Exemple de la vie

Cas négatif

Le testeur décide de couvrir toutes les fonctions et cas, en fin de compte, il manque de temps pour tester les chemins critiques, laissant passer les principaux bugs.

Avantages :

Beaucoup de scénarios testés formellement

Inconvénients :

Des bugs bloquants critiques passent inaperçus à cause de la dilution de l'attention
Retards dus à un volume de tests injustifié

Cas positif

Au début du sprint, le testeur participe à la planification, fixe le scope avec toute l'équipe, en mettant l'accent sur les scénarios utilisateur les plus importants, accorde le volume de travail et le documente dans Confluence.