Préparer une vérification utile

Les contraintes réglementaires, les interfaces, les données, les volumes et les engagements contractuels doivent être pris en compte.

Préparer des conditions représentatives, un résultat attendu et une procédure d’arrêt si le test devient perturbant. Conserver le résultat, les écarts et les corrections. Un test réussi sur un cas simple ne couvre pas automatiquement les exceptions ni les autres périmètres.

Exemple fictif : « afficher un dossier en moins de deux secondes pour la charge convenue » est testable, tandis que « application très performante » ne l’est pas.

Un seuil doit être justifié par l’usage. Éviter de promettre un niveau de service sans préciser sa méthode de mesure et ses exclusions.

Application à votre contexte

Définissez les préconditions, le scénario, le résultat attendu et le critère d'arrêt. Le test doit être autorisé et organisé sans mettre en danger la production ou les données.

Un schéma est une hypothèse de fonctionnement. Demandez à un utilisateur de raconter un dossier réel, y compris une exception et un retour en arrière. Notez les outils informels et les personnes indispensables plutôt que de les faire disparaître du dessin.

Remettre cette réponse dans son contexteExigences fonctionnelles et non fonctionnelles

Références pour approfondir