Test d'acceptation utilisateur UAT
La vérification que l'acheteur fait lui-même avant de signer, sur le vrai matériel et à partir de quelques journées de travail ordinaires.
Également appelé recette utilisateur tests d'acceptation UAT
Définition
Le test d'acceptation utilisateur, c'est le test que l'acheteur fait lui-même avant de signer la réception d'un nouveau système. Pas celui du prestataire. Le vôtre. Vous vous asseyez devant le logiciel et vous vérifiez qu'il fait le travail que vous avez payé.
La meilleure méthode est d'écrire quelques journées de travail ordinaires et de les rejouer une par une. Un client achète trois articles et paie moitié en espèces, moitié par carte. Un patient prend un rendez-vous, puis appelle pour le déplacer. Un parent demande un reçu de frais du trimestre dernier. Chacun de ces cas est un scénario. Écrivez-les avant de voir le logiciel, pour que la liste vienne de votre activité et non des écrans que quelqu'un a déjà dessinés.
Faites-les sur le vrai matériel. Les téléphones que vos employés portent vraiment, l'imprimante à tickets derrière le comptoir, le terminal de carte, le vieux portable du bureau. Un test sur la machine rapide d'un développeur ne prouve pas grand-chose. Quand Linkysoft livre un système de cabinet médical, nous demandons à la secrétaire de rejouer un mardi matin normal depuis son propre bureau, avec sa propre imprimante. La moitié des ennuis de la première semaine viennent d'une imprimante, d'une connexion lente ou d'un écran plus petit que prévu.
Décidez à l'avance qui signe. Une personne nommée de votre côté, en général celle à qui on reprochera un échec. Bloquez-lui du vrai temps dans l'agenda, une demi-journée, pas vingt minutes entre deux réunions. Mettez-vous ensuite d'accord sur le sort des problèmes découverts après la signature. C'est la partie que tout le monde saute. Demandez une garantie écrite, trente ou quatre-vingt-dix jours, pendant laquelle tout ce qui ne correspond pas aux scénarios convenus est corrigé sans frais.
L'erreur la plus fréquente est de ne tester que le chemin facile. Tout marche quand le client paie tout et ne rapporte rien. Testez le remboursement, le rendez-vous annulé, le prix erroné, l'employé parti le mois dernier. Chez Linkysoft, la liste des scénarios s'écrit avec le client avant le démarrage d'un projet d'application web, et la même liste ressert côté téléphone quand nous construisons l'application mobile. La discussion sur le sens du mot terminé a lieu au début, pas à la fin, quand elle coûte cher.
Questions sur Test d'acceptation utilisateur
Qui doit faire le test d'acceptation utilisateur ?
Est-ce la même chose que les tests déjà faits par les développeurs ?
Que se passe-t-il si on trouve un problème après avoir signé ?
Faut-il tester l'application mobile séparément ?
Vous ne voyez toujours pas comment cela s'applique à votre projet ?
Dites-nous ce que vous construisez et nous vous répondrons simplement.