Bases des Tests d'Utilisabilité: Ce que les Ingénieurs QA Doivent Savoir

Les tests d'utilisabilité évaluent si les utilisateurs peuvent accomplir des tâches efficacement et sans confusion, contrairement aux tests fonctionnels qui vérifient uniquement que les fonctionnalités fonctionnent comme spécifié.

Ce que sont les tests d'utilisabilité

Les tests d'utilisabilité, c'est l'observation structurée de vrais utilisateurs qui tentent d'accomplir de vraies tâches avec ton produit. Tu regardes ce qu'ils font, tu écoutes ce qu'ils disent, et tu notes où ils bloquent.

Le résultat n'est pas un succès ou un échec. C'est un retour qualitatif : où les utilisateurs se perdent, ce qu'ils tentent sans succès, quel vocabulaire ils utilisent qui ne correspond pas à celui de l'interface. On note aussi combien de temps prend quelque chose qui devrait être simple.

Les cinq composantes de l'utilisabilité (Nielsen)

Le modèle d'utilisabilité de Jacob Nielsen définit cinq dimensions :

Apprenabilité : à quel point est-il facile pour les nouveaux utilisateurs d'accomplir des tâches de base ? Efficacité : une fois maîtrisé, à quelle vitesse les utilisateurs expérimentés accomplissent-ils leurs tâches ? Mémorabilité : quand les utilisateurs reviennent après une longue absence, retrouvent-ils facilement leur niveau ? Erreurs : combien d'erreurs les utilisateurs commettent-ils, quelle est leur gravité, et s'en remettent-ils facilement ? Satisfaction : l'expérience est-elle agréable ?

Les produits pondèrent ces dimensions différemment. Un tunnel de paiement grand public optimise l'apprenabilité et la récupération d'erreurs. Un outil professionnel utilisé quotidiennement optimise l'efficacité.

Méthodes : du plus rapide au plus rigoureux

Évaluation heuristique (sans utilisateurs)

Un ingénieur QA ou un spécialiste UX évalue l'interface selon des heuristiques d'utilisabilité établies. Les 10 heuristiques de Nielsen sont la référence :

1. Visibilité de l'état du système : l'utilisateur sait-il ce qui se passe ?

2. Correspondance avec le monde réel : le vocabulaire correspond-il aux attentes des utilisateurs ?

3. Contrôle et liberté de l'utilisateur : peut-il annuler des actions et sortir des situations bloquantes ?

4. Cohérence et standards : l'interface suit-elle les conventions de la plateforme ?

5. Prévention des erreurs : le design évite-t-il les erreurs avant qu'elles surviennent ?

6. Reconnaissance plutôt que rappel : l'interface minimise-t-elle la charge mémorielle ?

7. Flexibilité et efficacité : y a-t-il des raccourcis pour les utilisateurs experts ?

8. Design esthétique et minimaliste : l'interface est-elle débarrassée des informations non pertinentes ?

9. Aide à la reconnaissance, au diagnostic et à la récupération d'erreurs : les messages d'erreur sont-ils précis et utiles ?

10. Aide et documentation : l'aide est-elle disponible et facile à trouver ?

C'est rapide et ne requiert aucun utilisateur. Une seule session de revue détecte 30 à 50 % des problèmes d'utilisabilité.

Tests d'utilisabilité guérilla

Cinq minutes, n'importe quel utilisateur, n'importe où. Montre un prototype ou le produit réel à quelqu'un. Donne-lui une seule tâche : "Peux-tu trouver où réinitialiser ton mot de passe ?" Observe. N'aide pas. Prends des notes.

Cinq utilisateurs par session. Tu trouveras les problèmes les plus évidents rapidement. Budget zéro.

Sessions modérées

Un facilitateur travaille avec un participant à la fois. Le participant "pense à voix haute" en tentant des tâches. Le facilitateur relance et creuse.

Les tests modérés à distance (via Zoom et partage d'écran) rendent ça accessible. Des outils comme UserTesting ou Maze fournissent des panels de participants.

Tests non modérés

Les participants accomplissent les tâches seuls, avec enregistrement de l'écran. Tu revois les enregistrements. Plus scalable que les sessions modérées, moins nuancé : impossible de creuser en temps réel.

Ce que les ingénieurs QA peuvent faire sans processus UX formel

Pendant les tests exploratoires : note les moments de confusion ou de frustration. "Le message d'erreur dit 'Saisie invalide' sans indiquer quel champ est en cause." C'est un défaut d'utilisabilité. Applique les 10 heuristiques : parcours chaque nouvelle fonctionnalité avec la liste de Nielsen. Vérifie chaque point systématiquement. Demande-toi si un nouvel utilisateur s'en sortirait : quand tu testes une fonctionnalité pour la première fois (sans lire la spec), fais attention à ta propre confusion. Tu es un proxy pour les nouveaux utilisateurs. Teste la récupération d'erreurs : que se passe-t-il quand un utilisateur fait une erreur courante ? Le message d'erreur est-il utile ? Y a-t-il un chemin clair pour corriger ? Teste sur mobile : beaucoup de problèmes d'utilisabilité sont spécifiques aux appareils. Zones de toucher trop petites pour être précises. Formulaires qui nécessitent de défiler de haut en bas. Modales qui débordent de l'écran.

Défauts d'utilisabilité courants à signaler

Messages d'erreur qui ne précisent pas ce qui s'est passé ni comment y remédier
Champs de formulaire qui se réinitialisent sur erreur (l'utilisateur doit tout ressaisir)
Champs obligatoires non signalés comme tels avant l'échec de la soumission
Boutons ou liens qui semblent cliquables sans l'être, ou qui ne semblent pas cliquables mais devraient l'être
Dialogues de confirmation sans distinction claire entre confirmer et annuler
États de chargement sans indication de progression ni du temps d'attente prévu
Actions sans possibilité d'annulation (notamment les actions destructives)
Terminologie incohérente (même fonctionnalité appelée différemment selon les parties de l'interface)
Pagination sans indication du nombre total de résultats ni de la position actuelle

Rédiger des défauts d'utilisabilité

Les défauts d'utilisabilité sont plus difficiles à rédiger que les défauts fonctionnels, parce qu'il n'y a pas de résultat attendu clair dans une spec. Formule-les en termes d'impact :

Mauvais : "Le message d'erreur est confus." Bon : "Quand un utilisateur soumet le formulaire d'inscription avec un email déjà enregistré, le message d'erreur affiche 'Une erreur s'est produite. Veuillez réessayer.' Les utilisateurs ne peuvent pas déterminer s'ils doivent changer d'email, utiliser un autre mot de passe, ou essayer de se connecter. La solution est d'afficher 'Cet email est déjà enregistré. Essayez de vous connecter.' avec un lien vers la page de connexion."

Le rapport de bug explique l'impact sur l'utilisateur et propose une correction précise. C'est ce qui fait prendre les problèmes d'utilisabilité au sérieux plutôt que de les balayer comme des "opinions de design".