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 ?
Les personnes qui utiliseront le système tous les jours, pas l'équipe technique. Une secrétaire, un caissier, un enseignant. Un responsable désigné signe à la fin.
Est-ce la même chose que les tests déjà faits par les développeurs ?
Non. Les développeurs vérifient que le code fonctionne comme ils l'ont écrit. Ici, on vérifie que le système fait le travail dont votre activité a besoin, décrit avec vos mots.
Que se passe-t-il si on trouve un problème après avoir signé ?
C'est le rôle de la garantie. Convenez-la par écrit avant de signer, en général trente à quatre-vingt-dix jours, pendant lesquels tout ce qui ne correspond pas aux scénarios convenus est réparé sans frais.
Faut-il tester l'application mobile séparément ?
Oui. Les écrans sont plus petits, la connexion tombe, et l'appareil photo et les alertes se comportent autrement. Rejouez les mêmes journées types sur les téléphones que vos employés portent vraiment.

Vous ne voyez toujours pas comment cela s'applique à votre projet ?

Dites-nous ce que vous construisez et nous vous répondrons simplement.