Des critères d’acceptation rédigés après la fin du développement ne sont pas des critères d’acceptation. Il s’agit d’une opinion formulée en examinant le résultat, et ils ne permettent de rien trancher.
Rédiger les critères avant le développement
Les critères d’acceptation décrivent comment vous déciderez qu’une fonctionnalité est terminée, et ils doivent exister avant son développement pour deux raisons : le développeur doit savoir vers quel résultat il travaille, et le client a besoin d’une norme qui n’a pas été influencée par le résultat.
Un critère exploitable est précis et testable :
- Faible : "La recherche devrait bien fonctionner."
- Exploitable : "Une recherche par nom de client renvoie les enregistrements correspondants en moins de deux secondes, reconnaît les noms partiels et n’est pas sensible à la casse."
Le second peut être testé par n’importe qui. Le premier ne peut pas être testé du tout.
Réaliser une UAT qui détecte les vrais problèmes
Un test d’acceptation utilisateur mené sous la forme de « regardez et dites-nous ce que vous en pensez » détecte les problèmes cosmétiques et passe à côté de ceux qui comptent. Une structure améliore considérablement le processus.
- Testez par flux de travail, pas par écran. Parcourez de bout en bout les tâches complètes qu’un utilisateur réel effectue. Les bugs se trouvent aux jonctions entre les écrans, pas sur les écrans eux-mêmes.
- Utilisez des données réalistes. Noms longs, caractères accentués, champs facultatifs vides, grandes quantités, dates aux limites des mois et des années. Des données de test propres masquent la plupart des problèmes de gestion des saisies.
- Testez délibérément les scénarios d’échec. Envoyez le formulaire deux fois. Saisissez un mauvais mot de passe cinq fois. Perdez la connexion à mi-parcours. Ce sont les scénarios auxquels les vrais utilisateurs sont confrontés et que les tests couvrent rarement.
- Faites tester le système par les utilisateurs réels. La personne qui l’utilisera quotidiennement détecte des problèmes que le sponsor ne verra jamais, car elle sait réellement en quoi consiste le travail.
- Consignez chaque constat au même endroit, avec les étapes permettant de le reproduire et une capture d’écran. Un constat qui ne peut pas être reproduit ne peut pas être corrigé.
Défaut ou changement
Chaque UAT produit des constats qui ne sont pas des défauts, et les classer équitablement permet d’éviter que le processus ne devienne conflictuel.
Un défaut est une différence entre ce qui a été convenu et ce qui a été développé. Il est corrigé aux frais du développeur.
Un changement est un élément qui fonctionne comme convenu, mais qui ne correspond plus à ce que le client souhaite. Il fait l’objet d’un devis séparé.
Les clients perçoivent souvent le second comme un défaut, parce que le logiciel fait quelque chose auquel ils ne s’attendaient pas. La réponse honnête n’est pas de débattre de l’étiquette, mais de se référer au critère convenu, puis de demander si le changement mérite d’être réalisé. Beaucoup ne le méritent finalement pas.
La gravité, qui détermine ce qui bloque le lancement
Tous les défauts ne doivent pas être corrigés avant la mise en production, et les considérer tous comme bloquants retarde les lancements sans aucun bénéfice. Une classification simple en trois niveaux, convenue à l’avance :
- Bloquant — un flux de travail essentiel ne peut pas être terminé, des données sont perdues ou corrompues, ou un problème de sécurité existe. Doit être corrigé avant le lancement.
- Majeur — une fonctionnalité fonctionne incorrectement, mais une solution de contournement existe. Corrigé avant le lancement si le temps le permet, sinon planifié avec une date.
- Mineur — problèmes cosmétiques, formulation, petites incohérences. Regroupés dans une version postérieure au lancement.
Convenir de cette classification avant le début de l’UAT transforme un désaccord sur l’urgence en une évaluation partagée.
Ce que la validation engage pour les deux parties
La validation doit avoir une signification précise : les critères convenus sont respectés, les éléments mineurs restants sont listés avec leurs dates, et le jalon de paiement est libéré. Elle marque le début de la période de garantie, pendant laquelle les défauts découverts ultérieurement sont corrigés sans frais.
Elle ne signifie pas que le client ne pourra plus jamais signaler un problème, et un contrat qui le laisserait entendre serait déraisonnable. La période de garantie couvre les défauts qu’une UAT raisonnable n’aurait pas détectés.
Le temps à prévoir
L’UAT est systématiquement sous-planifiée. Pour un petit projet, prévoyez une à deux semaines — suffisamment de temps pour que les utilisateurs réels testent le système dans le cadre de leur travail, que les constats soient corrigés et qu’un nouveau test soit effectué.
La réduire à deux jours produit une validation qui ne signifie rien, et les problèmes apparaissent plutôt durant la première semaine d’utilisation en production, lorsqu’ils coûtent plus cher et sont bien plus visibles.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels métier pour les systèmes de CRM, de réservation, de gestion des stocks et de flux de travail.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion backend.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander une revue du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.