Test d'utilisabilité Protocole de test

Test d'utilisabilité Protocole de test -
Conseils..

| consulter également Rapport de tests des membres de FullTests.

Test d'utilisabilité Protocole de test - Conseils... | L'auteur d'un logiciel n'a souvent pas le recul nécessaire pour évaluer son oeuvre.
Voici un protocole de tests objectifs.
Voir le site FullTests.com Fulltest

Test d'utilisabilité Protocole de test - Conseils. http://www.usabilis.com/ - Site dédié
L'article original peut être consulté ici : http://www.usabilis.com/pratique/test.htm

Le test d'utilisabilité est la méthode la plus efficace pour évaluer un logiciel car il permet d'observer directement la façon dont l'utilisateur se sert de l'application et ainsi d'identifier concrètement les véritables problèmes qu'il rencontre en situation d'utilisation.

Il consiste à placer l'utilisateur final en situation effective d'utilisation du logiciel et à lui demander de réaliser au mieux la tâche pour laquelle le logiciel a été conçu.
Il est alors possible de déterminer de façon objective l'utilisabilité du produit en mesurant la performance de l'utilisateur, par exemple : a-t-il pu accomplir la tâche correctement et dans le temps voulu ?
Le test d'utilisabilité est aussi et surtout l'occasion de voir l'utilisateur en situation et d'observer les problèmes qu'il rencontre, les questions qu'il se pose, ainsi que les fonctionnalités qu'il apprécie ou non.
Les équipes de développement peuvent ainsi recueillir des éléments précieux sur la façon de rendre le logiciel plus facile à utiliser car mieux adapté aux besoins du client visé.

La norme ISO 9241-11 définit l'utilisabilité de la manière suivante.
Un système est utilisable lorsqu'il permet à l'utilisateur de réaliser sa tâche avec efficacité, efficience et satisfaction dans le contexte d'utilisation spécifié.
En d'autres termes, on considère qu'un logiciel est utilisable lorsque l'utilisateur peut réaliser sa tâche (efficacité), qu'il consomme un minimum de ressources pour le faire (efficience) et que le système agréable à utiliser (satisfaction). Tester l'utilisabilité d'un système consiste donc à valider ces trois critères :
Efficacité : Vérifier que les objectifs visés par l'utilisateur sont atteints.
Efficience : Mesurer les ressources nécessaires pour atteindre ces objectifs, par exemple le temps que l'utilisateur met pour réaliser la tâche.
Satisfaction : Déterminer si le système est agréable à utiliser, par exemple le critère de satisfaction peut être inversement proportionnel au nombre de remarques négatives émises par les utilisateurs.
La norme définit l'utilisabilité sur la base de ces 3 caractéristiques. Il s'agit effectivement des points les plus représentatifs dans le cas général. Cependant, il peut être utile, selon les spécificités de l'application, d'évaluer d'autres aspects du logiciel :
Sécurité : Nombre d'erreurs commises par l'utilisateur et rapidité de correction des erreurs.
Facilité d'apprentissage : Compréhension correcte et assimilation rapide du mode de fonctionnement du logiciel. Qui plus est, en phase de développement, le test d'utilisabilité permet aussi de valider des hypothèses faites sur le comportement de l'utilisateur au moment de la conception du logiciel, par exemple la façon dont il navigue dans l'interface, les informations qu'il recherche ou les commandes dont il se sert le plus souvent.

Protocole de test
Le test d'utilisabilité consiste à se placer dans un contexte le plus proche possible de l'utilisation réelle du logiciel. L'observateur donne différentes consignes qui vont conduire l'utilisateur à effectuer des activités spécifiques du logiciel. Pour chacune d'entre elles, des mesures sont réalisées afin de vérifier si les critères d'utilisabilité sont atteints.
Le principal intérêt du test est qu'il permet d'observer l'utilisateur dans le contexte réel d'utilisation. Il est donc essentiel de ne pas l'aider (sauf bien entendu en cas d'impasse). En effet, afin d'identifier clairement les problèmes, il importe de laisser l'utilisateur "se débrouiller" comme il le fera quand il sera seul face au logiciel.
L'observateur note les erreurs commises, les incompréhensions, les impasses, tout événement qui montre une difficulté d'utilisation du logiciel. Ces différentes observations font l'objet, une fois le test terminé, d'une analyse "à chaud" avec l'utilisateur, afin de mieux comprendre les causes des problèmes. Des solutions originales naissent généralement de ces réunions.
Afin de préparer le test et de pouvoir le reproduire dans des conditions similaires pour chaque utilisateur, il est utile d'établir clairement le protocole en précisant :
Les conditions matérielles dans lesquelles le test est réalisé, Le profil des utilisateurs, Les différents scénarios. Ceux-ci vont être garants de l'exhaustivité du test et de la bonne couverture du logiciel. On précisera pour chacun d'entre eux la consigne donnée aux utilisateurs, l'objectif que l'on cherche à valider et les mesures effectuées. Il est à noter qu'au-delà d'une exigence de tracabilité, le protocole de test vise également à préciser les limites d'exploitation des résultats.

Conseils
Il arrive, lors du test, que l'utilisateur n'ose pas dire qu'il ne réussit pas à se servir du logiciel. Il préfère cacher ses difficultés, rendant caduques les résultats du test. C'est pourquoi il est essentiel de mettre en confiance l'utilisateur au début de la séance en lui rappelant que c'est au logiciel de s'adapter à l'individu et non le contraire.

Le test vise à évaluer le logiciel, pas l'utilisateur.
Si l'utilisateur ne réussit pas à se servir du logiciel, c'est que le logiciel a été mal conçu. L'objectif du test est d'identifier les problèmes d'utilisabilité de l'application et non de mesurer la capacité de l'utilisateur à se servir du logiciel.

Définir un objectif précis par séance de test.
Lorsque le scénario du test est bien ciblé, qu'il répond à un objectif précis, les résultats du test sont aisément exploitables. Dans le cas contraire, le résultat peut être source d'interprétations multiples, ne facilitant pas la révision du logiciel. En règle générale, une bonne adéquation entre l'objectif de la séance, les utilisateurs impliqués et le scénario permet de garantir la représentativité des résultats. C'est pourquoi, une attention toute particulière doit être portée à l'élaboration du protocole de test. Une phase de "pré-test" avec les membres de l'équipe de développement est généralement utile.

Choisir un panel utilisateur représentatif.
Les utilisateurs doivent être ceux visés par l'application évaluée. Il est essentiel que soit ceux qui effectivement utiliseront le logiciel, sinon les résultats risquent de ne pas être pertinents. Il arrive parfois qu'on rencontre des "abonnés aux expérimentations" qui participent à de nombreux tests. Cette présence témoigne de leur motivation. Ce sont généralement des sujets imaginatifs. Mais sont-ils vraiment représentatifs des utilisateurs ? Leurs fréquentes participations aux expérimentations ne biaisent-elles pas leur appréhension du logiciel ? Pour des applications grand public, il est préférable de changer fréquemment la composition du panel utilisateur.

5 utilisateurs suffisent. J. Nielsen a montré que des tests menés avec 5 utilisateurs permettent de lever au moins 80 % des problèmes d'utilisabilité. En effet, ce n'est pas en augmentant le nombre d'utilisateurs que l'on trouve plus de problèmes. Les problèmes sont liés au logiciel, pas aux utilisateurs ! Tester avec un plus grand nombre d'utilisateurs augmente le coût du test, pas la pertinence des résultants. Plutôt que de mener un test avec 15 utilisateurs, J. Nielsen considère qu'il est préférable de faire 3 tests avec 5 utilisateurs, en améliorant l'interface à chaque itération. Bien entendu, lorsque l'application vise différents types d'utilisateurs, il importe de tester auprès des différents groupes (pour plus de détail, voir l'article de J. Nielsen

Mise à jour le :