Pourquoi tester aussi les cas difficiles ?

Définir ce qu’un résultat acceptable signifie

Nous définissons avec vous une situation de départ, une période de comparaison et les critères de réussite du processus retenu. Nous testons les résultats et les cas d’erreur, puis confrontons les bénéfices estimés aux observations en tenant compte des coûts réels et du travail de contrôle. Le temps libéré, son utilisation et les effets économiques sont distingués ; aucun retour sur investissement n’est garanti.

Pour chaque étape retenue, décrivez le résultat attendu et la manière de le vérifier. Une réponse bien écrite n’est pas nécessairement correcte ; une information extraite peut être incomplète ; une relance pertinente peut encore viser un mauvais destinataire. Le critère doit porter sur le travail réel.

Les indicateurs suggérés à l’audit restent à préciser et à vérifier pendant la conception et les tests. À ce stade, ils orientent la décision ; ils ne constituent pas des résultats déjà obtenus.

Prévoir les situations qui sortent du cas courant

Examinez les cas courants avec des exemples autorisés, puis les situations difficiles que les personnes rencontrent. Le but n’est pas d’obtenir une réponse à tout prix, mais de vérifier que l’étape produit le résultat convenu ou demande une intervention lorsqu’elle ne peut pas le faire.

• Une donnée nécessaire est absente ou deux informations se contredisent.
• Un document présente un format inhabituel ou une demande est ambiguë.
• Le résultat proposé est incertain et demande une vérification.
• Une action exige une validation, qui est refusée ou n’arrive pas.
• Une étape ne peut pas aboutir et doit signaler le problème ou s’arrêter.

Corriger les écarts et conserver les limites

Les écarts observés servent à corriger la solution avant la mise en place du périmètre retenu. Les limites encore présentes doivent être connues des utilisateurs. Le déploiement progressif permet ensuite de comparer le fonctionnement aux critères convenus.

L’audit n’inclut ni prototype, ni développement, ni connexion aux logiciels, ni mise en production. La conception, les intégrations, les tests et la prise en main relèvent d’un devis de déploiement distinct.

Un test réussi sur les cas retenus ne garantit pas tous les résultats futurs. Les observations doivent rester attachées au périmètre évalué et aux conditions dans lesquelles il fonctionne.