Une équipe livre un jour un système de dépenses qui réussit tous les tests techniques. Dès le premier jour, l’équipe financière découvre qu’elle ne peut pas gérer les créances multidevises, qui représentent une grande partie de son travail. Rien n’était “cassé”, mais ce n’était pas utilisable. Les tests d’acceptation des utilisateurs existent pour combler exactement ce type d’écart avant le lancement.

Ce guide explique en quoi l’UAT diffère des autres tests, comment l’exécuter étape par étape et comment décider quand vous êtes prêt à le publier. Le scénario ci-dessus et les exemples ci-dessous sont illustratifs et le processus doit être adapté à votre projet.

Qu’est-ce que l’UAT ?

L’UAT constitue généralement la phase de test finale avant la sortie, au cours de laquelle les utilisateurs prévus confirment que le logiciel peut faire son travail dans des conditions réalistes. On l’appelle également test utilisateur final ou test d’acceptation. Cela intervient après le développement et les tests du système, lorsque le produit est censé être stable.

Son but n’est pas de trouver tous les bugs. À ce stade, la plupart d’entre eux devraient déjà avoir disparu. L’objectif est la validation : avons-nous construit la bonne chose ? Les testeurs vérifient que le produit correspond aux spécifications. L’UAT valide que la spécification et le produit répondent réellement au besoin.

Tests UAT vs QA

L’UAT ne remplace pas les autres tests. Si les utilisateurs continuent de rencontrer des bugs de base, la version n’était pas prête et vous perdez leur temps limité. Ces problèmes appartiennent aux niveaux de test antérieurs et aux tests de régression.

Qui dirige l’UAT ?

Choisissez des testeurs qui font vraiment le travail aujourd’hui. Un gestionnaire de sinistres expérimenté détectera des problèmes qu’un gestionnaire ou un mandataire ne détecterait jamais. Incluez une gamme d’expériences, car un nouvel employé révèle souvent des étapes déroutantes qu’un expert contourne sans s’en apercevoir. Et assurez-vous que leurs responsables libèrent du temps pour cela, car l’UAT ne peut pas réussir avec une charge de travail complète.

Types d’UAT

Le processus UAT en sept étapes

1. Définir la portée et les objectifs

Décidez de ce qui est accepté, de ce qui est hors de portée et des résultats commerciaux qui comptent. Par exemple : « Le personnel financier peut soumettre, approuver et payer une note de frais, dans n’importe quelle devise prise en charge. »

2. Convenez des critères d’acceptation

Écrivez en langage simple à quoi ressemble le succès, idéalement au début du projet plutôt que la semaine précédant le lancement. Des critères vagues conduisent ensuite à des disputes.

3. Choisir et briefer les testeurs

Sélectionnez de vrais utilisateurs, expliquez-leur le but, montrez-leur comment enregistrer les commentaires et indiquez clairement qu’ils testent le logiciel plutôt que d’être testés eux-mêmes. Beaucoup de gens craignent de se tromper.

4. Préparer l’environnement et les données

L’environnement UAT doit ressembler autant que possible à la production. Utilisez des données réalistes, configurez les rôles d’utilisateur appropriés et vérifiez les intégrations telles que la messagerie électronique. Si vous copiez des données de production, masquez d’abord les informations personnelles. Exécutez un smoke test rapide, afin que les testeurs n’arrivent pas à trouver une version cassée.

5. Écrivez des scénarios

Basez-les sur des flux de travail réels plutôt que sur des boutons individuels. Ils devraient lire comme le travail, pas comme le logiciel. Notre guide sur le cas de test par rapport au scénario de test explique le niveau de détails dont vous avez besoin.

6. Exécutez les tests et collectez des commentaires

Organisez des sessions avec une personne disponible pour vous aider. Regroupez les problèmes en un seul endroit, avec des captures d’écran. Prévoyez également du temps pour l’exploration libre, car les gens essaient des choses que les scripts n’ont jamais anticipées. Les tests exploratoires proposent des techniques utiles pour cela.

7. Corrigez, retestez et déconnectez-vous

Triez les commentaires, corrigez ce qui compte et demandez aux mêmes utilisateurs de confirmer les correctifs. Enregistrez ensuite une décision formelle.

Un cas de test UAT

Un cas de test UAT devrait être facile à suivre pour une personne non technique. Voici un exemple de système de dépenses :

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

A noter qu’il décrit une tâche réelle, pas des détails techniques, et qu’il laisse place aux commentaires. Ces commentaires s’avèrent souvent être la partie la plus précieuse, comme « cela fonctionne, mais je ne trouverais jamais ce bouton ».

Critères d’entrée et de sortie

Ceux-ci s’inscrivent dans le cycle de vie des tests logiciels plus large. Définissez les chiffres avec vos parties prenantes à l’avance. « Nous déciderons quand cela nous semblera approprié » a tendance à conduire à un oui précipité, motivé par le délai.

Gestion des commentaires

Les retours UAT sont un mélange de choses, et tout n’est pas un bug. Triez-le en catégories :

Utilisez des règles claires pour déterminer ce qui bloque une version, comme décrit dans gravité vs priorité. Et répondez à chaque élément, y compris ceux que vous refusez. Les gens arrêtent de donner leur avis si celui-ci semble disparaître. Notre guide sur comment rédiger un rapport de bug peut aider les testeurs à décrire clairement les problèmes.

Liste de contrôle UAT

Avant l’UAT

• Les critères de portée et d’acceptation sont convenus par écrit
• Les tests système et de régression sont terminés
• Les testeurs sont choisis, briefés et disposent de temps
• L’environnement, les comptes et les données réalistes sont prêts
• Les données personnelles contenues dans les copies ont été masquées
• Les scénarios sont revus par le business
• Un endroit pour enregistrer les problèmes est mis en place
• Le propriétaire de la signature est nommé

Pendant l’UAT

• Un contact d’assistance est disponible
• Les problèmes sont triés quotidiennement
• Les progrès sont partagés avec les parties prenantes
• Les correctifs sont déployés et retestés de manière contrôlée

Après l’UAT

• Les critères de sortie ont été vérifiés
• Les problèmes connus sont documentés, avec les propriétaires
• L’approbation formelle est enregistrée
• Les notes de formation et de version sont mises à jour
• Une courte rétrospective a eu lieu

UAT dans les équipes Agile

L’UAT traditionnelle se présente comme une grande phase finale, où une surprise coûte cher. Les équipes agiles raccourcissent cette boucle. Les propriétaires de produits examinent chaque histoire par rapport à ses critères d’acceptation pendant le sprint, et les utilisateurs voient le logiciel fonctionnel lors des revues de sprint. De nombreuses équipes exécutent encore un UAT ciblé avant une version majeure, en particulier lorsque plusieurs fonctionnalités sont combinées en un seul flux de travail.

Avec des versions fréquentes, des techniques telles que les indicateurs de fonctionnalités et les déploiements Canary permettent aux vrais utilisateurs d’essayer progressivement de nouveaux travaux. Notez que ceux-ci complètent les tests d’acceptation, mais ne les remplacent pas automatiquement, en particulier dans les secteurs réglementés qui ont besoin d’un enregistrement formel.

Erreurs courantes

• Le traiter comme une formalité. Une signature sans réelle utilité ne protège personne.
• Utiliser les mauvais testeurs. Les développeurs et le contrôle qualité ont trop de connaissances sur le système pour représenter les utilisateurs.
• Commencer avec une version instable. Les testeurs perdent rapidement confiance et intérêt.
• Laisser cela jusqu’à la dernière minute. Vous n’avez alors pas le temps de corriger ce que vous apprenez.
• Utilisation de données irréalistes. Les données de test présentent rarement les cas compliqués que connaît le travail réel.
• Laisser la portée s’élargir. Traitez les nouvelles idées comme des demandes de changement, à moins qu’elles ne soient de véritables bloqueurs.

Pour conclure

L’UAT est votre dernière chance de savoir, avant sa sortie, si le logiciel aide réellement les personnes qui l’utiliseront. Planifiez-le dès le début d’un projet, recrutez de vrais utilisateurs et convenez de ce à quoi ressemble le succès. Pour votre prochaine version, essayez un changement simple : asseyez-vous avec un utilisateur pendant un scénario réel et ne dites rien pendant qu’il travaille.

Questions fréquentes

Continuez à apprendre