web-dev-qa-db-fra.com

Comment évaluer une application console?

Je dois effectuer une évaluation de l'utilisateur final sur une application console.

  • l'application est une sorte de bibliothèque de logiciels, c'est-à-dire une série de commandes qu'un programmeur peut utiliser pour effectuer certaines tâches spécifiques
  • les commandes sont une sorte d'interface de ligne de commande: au lieu d'appuyer sur des boutons, les utilisateurs peuvent assembler les commandes pour effectuer des choses compliquées (comme une composition des résultats générés par ces commandes)

Je pensais à un test d'utilisabilité, mais j'ai quelques doutes. Dans ce qui suit, j'essaie de le montrer.


Faisons un exemple.

Supposons que ma bibliothèque soit composée de deux commandes, c'est-à-dire

  1. computeRectangleArea(B, H) calcule l'aire d'un rectangle
  2. computeTriangleArea(B, H) calcule l'aire d'un triangle

Si je devais effectuer un test d'utilisabilité, je:

  1. définir un cas d'utilisation, par exemple, calculer l'aire d'un rectangle
  2. définir un objectif pour un tel cas d'utilisation, par exemple, calculer l'aire du rectangle R ayant une hauteur = 8 et une base = 3
  3. définir l'ensemble des actions nécessaires pour atteindre l'objectif (qui dans ce cas appelle simplement computeRectangleArea(3,8))

Dans ce cas, si l'utilisateur devine la bonne séquence d'actions à effectuer (qui n'est qu'une seule), le test d'utilisabilité réussit, sinon j'ai augmenté le taux d'échec.


Mes doutes

Je vois la possibilité de faire effectuer à l'utilisateur un test d'utilisabilité avec cette bibliothèque, mais je crains que:

  • les cas d'utilisation peuvent devenir très compliqués, nécessitant beaucoup d'étapes, beaucoup de commandes à écrire et à lancer
  • ces cas d'utilisation compliqués peuvent être difficiles à valider, car je crains que les utilisateurs ne devinent pas quelle est la bonne séquence d'actions et de commandes, ce qui peut donc augmenter considérablement le taux d'échec

Cela dit, je ne sais pas comment obliger mes utilisateurs à évaluer une telle bibliothèque de logiciels. La bibliothèque a été écrite selon un ensemble d'exigences utilisateur, et je vois que j'en ai besoin pour la tester et voir si elle couvre les exigences utilisateur spécifiées au début, si elle est satisfaite, si elle a besoin d'être affinée, etc. . Mais je crains qu'un test d'utilisabilité ne soit pas réalisable.


Des suggestions sur la façon d'effectuer cette évaluation de l'utilisateur final?

Merci.

4
Eleanore

Les utilisateurs de l'application sont les utilisateurs finaux, mais pour une bibliothèque, les utilisateurs sont des développeurs. Alors testez avec eux. Pour les développeurs, cela est déjà connu sous le nom de test unitaire.

1
John Doe IV

Tout d'abord, il est formidable que vous tentiez de faire des évaluations d'utilisabilité sur n'importe quelle application, sans parler d'une application console.

Je pense que vous devriez éviter de les considérer comme des "cas d'utilisation" afin de ne pas vous retrouver piégé dans la mentalité d'un développeur. Vous essayez de créer des scénarios de test pour un test d'utilisabilité.

Permettez-moi de répondre à vos doutes:

  • "les cas d'utilisation peuvent devenir très compliqués": Oui, dans des applications plus complexes, les scénarios que vous testez peuvent être très complexes, mais un logiciel qui fait quelque chose de significatif aura un certain niveau de complexité. Les postes de pilotage d'avion subissent des recherches sur les facteurs humains et ces choses sont méchantes et compliquées.
  • "Je crains que les utilisateurs ne devinent pas quelle est la bonne séquence d'actions et de commandes": c'est effectivement la raison de faire une évaluation de l'utilisabilité, non?

Donc, pour moi, vos doutes montrent seulement que vous vous dirigez dans la bonne direction, il vous suffit d'être prudent sur la façon de procéder. Je commencerais par comprendre certains objectifs , mesures et métriques . Ceux-ci peuvent aider à informer vos scénarios de test.

Déterminez si vous souhaitez vous concentrer sur les performances (combien de temps il faut aux utilisateurs pour faire quelque chose), les performances perçues (combien de temps ils ont ressenti il leur a fallu pour le faire), satisfaction , capacité d'apprentissage , ou un autre facteur. Il existe également des "outils" qui existent déjà pour obtenir un "score" général pour l'utilisabilité d'un logiciel, tels que SUS , mais vous devrez peut-être quelque chose de plus spécifique. J'essaierais d'obtenir plusieurs types de données - quantitatives et qualitatives - pour avoir plus confiance en vos résultats.

Un objectif axé sur la capacité d'apprentissage pourrait être "les utilisateurs doivent rarement vérifier la documentation après 10 minutes d'utilisation". La mesure serait "nombre de vérifications de documentation" et la mesure pour cela pourrait être aussi stricte que "nombre de man <command> utilise "si votre application a un page de manuel . Ensuite, vous pouvez construire un scénario de test qui répond à cet objectif.

Un objectif axé sur les performances perçues pourrait être "les utilisateurs peuvent trouver des zones de formes dans un délai raisonnable". La mesure consisterait en des réponses à une question posée après une tâche: "Avez-vous ressenti que cette tâche a pris plus de temps que prévu ou un temps raisonnable?" La métrique est le nombre de chaque réponse. Attention: ces questions peuvent être difficiles à obtenir et les utilisateurs peuvent être partiaux pour dire que tout va bien quand ce n'est pas le cas. Il est généralement mieux d'observer les actions que d'écouter ce que disent les utilisateurs.

Une dernière chose qui semble mineure mais qui est importante: dans vos scénarios de tâche, ne réutilisez pas un langage qui aide les utilisateurs à terminer la tâche. Dans l'exemple d'utilisation que vous avez donné, "calculer l'aire d'un rectangle" fait partie de la commande computeRectangleArea. Le cas d'utilisation donnerait à l'utilisateur 3 des mots nécessaires pour terminer la tâche. Essayez quelque chose comme "étant donné la hauteur et la largeur de cette forme, trouvez sa surface". Il contient toujours la "zone" de mot et augmente les frais généraux cognitifs pour que les utilisateurs déterminent si la forme est un rectangle ou non, mais cela semble être un scénario plus réel et évite de donner la commande entière.

1
Michael