Test d'acceptation des utilisateurs (UAT)

Les tests d'acceptation utilisateur constituent l'étape finale de validation au cours de laquelle les représentants de l'entreprise ou de la communauté d'utilisateurs confirment qu'un système répond aux exigences pour lesquelles il a été conçu et qu'il est adapté à l'usage prévu. Ils sont menés après les tests fonctionnels, généralement dans un environnement proche de la production, et leur résultat permet de décider de la mise en production.

Il répond à une question différente de celle posée par les tests précédents. Les tests de développement et d'assurance qualité vérifient si le système se comporte comme prévu ; les tests d'acceptation vérifient si les spécifications répondent effectivement aux besoins métier. Un système peut réussir tous les tests fonctionnels et échouer aux tests d'acceptation, soit parce que les spécifications étaient incomplètes, soit parce qu'un processus a été mal compris, soit encore parce qu'un cas concret non documenté n'a pas été pris en compte.

La confusion la plus grave concerne l'opposition entre tests d'acceptation et tests d'utilisabilité. Les tests d'acceptation font appel à des personnes connaissant le processus métier, qui analysent différents scénarios pour vérifier que le système les prend en charge. Les tests d'utilisabilité, quant à eux, observent des utilisateurs représentatifs interagir avec le produit sans aucune assistance, afin de déterminer s'il est compréhensible et utilisable. Confondre l'un et l'autre est une grave erreur : un système peut être accepté par des parties prenantes compétentes et rester inutilisable par les personnes pour lesquelles il a été conçu.

La sélection des participants détermine les résultats que l'exercice peut révéler. Les tests menés par l'équipe projet, ou par les parties prenantes impliquées depuis le début et connaissant le fonctionnement prévu du système, valident la conformité de la version aux attentes et ne révèlent que peu d'éléments nouveaux. Inclure les personnes qui utiliseront réellement le système et qui n'ont pas participé à sa conception permet de mettre en évidence les écarts entre le processus prévu et le processus mis en œuvre.

La conception des scénarios doit s'appuyer sur le travail réel plutôt que sur des listes de fonctionnalités. Analyser les tâches opérationnelles que le système doit prendre en charge, y compris les exceptions problématiques qui constituent une part importante de la pratique, permet de déceler des problèmes qu'une vérification fonctionnalité par fonctionnalité ne révèle pas. L'utilisation de données réalistes est tout aussi importante, car les systèmes qui fonctionnent correctement avec des données de test propres rencontrent fréquemment des difficultés avec les enregistrements malformés, incomplets et inhabituels présents en production.

Cette étape est structurellement vulnérable à la compression, car elle intervient à la fin d'un planning généralement déjà distancé. Les tests d'acceptation sont alors menés en un temps record, les participants devant les intégrer à leurs responsabilités habituelles, et les anomalies détectées sont priorisées pour être corrigées après le lancement. Planifier cette étape avec une durée réaliste, garantir la disponibilité des participants à l'avance et définir préalablement le seuil de gravité des anomalies susceptibles de retarder une mise en production sont autant d'éléments qui évitent qu'elle ne devienne une simple formalité.

Les critères de triage des défauts doivent être définis avant le début des tests, plutôt que négociés sous la pression une fois les résultats connus. Déterminer quelles catégories de problèmes bloquent la mise en production, lesquelles sont corrigées immédiatement et lesquelles sont consignées pour une utilisation ultérieure permet d'éviter les désaccords au moment où la pression commerciale est la plus forte et où le jugement est le moins fiable.

L'acceptation confirmant l'adéquation du système à l'usage prévu sans toutefois se prononcer sur sa capacité réelle d'utilisation par les utilisateurs finaux, les deux formes de validation sont nécessaires. En pratique, la phase d'acceptation est planifiée au sein de celle-ci. le développement de produits dans le cadre du processus de publication, la question distincte de savoir si les utilisateurs réels peuvent accomplir leurs tâches est résolue par le biais de recherche d'utilisateurset pour les systèmes internes, le réalisme opérationnel des scénarios dépend généralement de l'implication des Département IT et les équipes qui assureront le support du système après son lancement.