Les tests UX et les tests UI posent deux questions différentes
| Tests UI | Le bouton enregistre-t-il la fiche. La liste se rafraîchit-elle. Vérifiable objectivement. Automatisable. À exécuter à chaque modification. |
| Recherche UX | L'utilisateur a-t-il su trouver le bouton. A-t-il compris le résultat. Exige des personnes. Ne peut pas être automatisée et ne doit pas être simulée. |
Un produit peut passer tous les tests UI et rester pénible à utiliser. Il peut aussi enchanter pendant une session d'utilisabilité et perdre des données en production. Aucune des deux activités ne remplace l'autre.
Ce que l'automatisation peut honnêtement prendre en charge
L'exactitude fonctionnelle de chaque parcours. Toute la première colonne.
Les vérifications mécaniques d'accessibilité. Libellés manquants, contraste, ordre de focus. Une vraie valeur, qui ne couvre pas toute l'accessibilité.
Les vérifications de cohérence. Savoir si la même action se comporte de la même façon à trois endroits, un problème UX qui a une forme testable.
Ce qu'elle ne peut pas faire
Si le parcours avait du sens. Si le message d'erreur a aidé. Si quelqu'un a abandonné. Cela demande des personnes, et la bonne façon de voir les choses est que l'automatisation rachète le temps de les faire en supprimant la passe de régression manuelle.
La zone de recouvrement qui mérite d'être automatisée
Il existe une bande étroite où les deux se rejoignent vraiment, et c'est l'automatisation la plus sous-exploitée à la portée de la plupart des équipes.
La cohérence est une propriété UX qui a une forme testable. La même action produit-elle la même confirmation aux trois endroits où elle apparaît. Une erreur ressemble-t-elle à une erreur partout, ou bien un écran échoue-t-il en silence. L'action principale occupe-t-elle la même position dans chaque fenêtre modale. Rien de tout cela ne demande de juger si le design est bon, et tout cela, les utilisateurs le perçoivent comme de la négligence.
Ces écarts sont aussi invisibles pour ceux qui ont construit chaque écran, parce que chaque écran est cohérent avec lui-même. Les vérifier d'un écran à l'autre coûte peu et permet de détecter une catégorie de plaintes que ni les tests fonctionnels ni la recherche sur l'utilisabilité ne cherchent.
Le piège
Les équipes réduisent la recherche UX parce que la couverture des tests UI est élevée. Le raisonnement paraît solide et constitue une erreur de catégorie : la couverture dit que le produit fait ce pour quoi il a été construit, et ne dit rien sur la pertinence de ce qui a été construit.
L'organisation la plus saine consiste à confier les vérifications répétitives à l'automatisation et à consacrer les heures ainsi libérées à la recherche que seules des personnes peuvent mener.
Rien de tout cela n'exige un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage courant et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter la même chose depuis la ligne de commande s'ils le préfèrent, ce qui est documenté dans le dépôt CLI.
Le déclencheur compte plus que le mécanisme. Le brancher sur votre événement de déploiement, c'est faire vérifier chaque modification sans que personne ait à le décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.
Ce que TestSprite automatise, et ce qu'il vous laisse
Il automatise toute la colonne fonctionnelle : le parcours fonctionne-t-il, l'état se transmet-il correctement d'une étape à l'autre, ce qu'on annonce à l'utilisateur correspond-il à ce qui s'est réellement passé. Les cas sont générés à partir de votre produit et affinés en langage courant, et ils s'exécutent à chaque modification.
Il couvre aussi les vérifications de cohérence qui se situent dans la zone de recouvrement, par exemple si la même action se comporte de la même façon partout où elle apparaît, une plainte UX qui a une forme testable.
Ce qu'il vous laisse délibérément, c'est la recherche. L'intérêt de supprimer la passe de régression manuelle, ce sont les heures qu'elle restitue, et la thèse de cette page est que ces heures devraient servir à parler aux utilisateurs plutôt qu'à retourner dans le backlog.
L'IA peut-elle faire des tests d'utilisabilité ?
Elle peut simuler des parcours dans une interface, ce qui est utile pour la couverture. Elle ne peut pas vous dire si une vraie personne serait déroutée, parce que c'est un fait qui concerne les personnes.
L'accessibilité relève-t-elle de l'UX ou de l'UI ?
Des deux. Les parties mécaniques s'automatisent bien, les parties expérientielles demandent des personnes, idéalement des personnes qui utilisent des technologies d'assistance.
À quelle fréquence faut-il mener de la recherche UX ?
Quand quelque chose change en profondeur ou quand les indicateurs montrent que les gens abandonnent. Pas à un rythme fixe pour le principe.
Qui est responsable de chacun ?
Les tests UI relèvent en général de l'ingénierie. La recherche UX relève du design ou du produit. Les problèmes apparaissent quand on suppose qu'une seule équipe couvre les deux.
Une bonne UX réduit-elle le besoin de tests UI ?
Non. Un parcours bien conçu peut toujours être cassé par une modification du code, et c'est précisément ce que les tests UI détectent.
L'un demande si ça fonctionne, l'autre si ça vaut la peine d'être utilisé.
Les tests UX et les tests UI répondent à des questions différentes. Automatisez la moitié fonctionnelle, accessibilité mécanique comprise, et consacrez le temps ainsi libéré à la recherche qui exige des personnes. Une couverture élevée n'est pas une raison d'arrêter de parler aux utilisateurs.