web-dev-qa-db-ja.com

コンソールアプリケーションの評価方法は？

コンソールアプリケーションでエンドユーザー評価を実行する必要があります。

  • アプリケーションは、一種のソフトウェアライブラリ、つまり、プログラマーが特定のタスクを実行するために使用できる一連のコマンド
  • コマンドは一種のコマンドラインインターフェイスです。ボタンを押す代わりに、ユーザーはコマンドを組み立てて複雑なことを実行できます（これらのコマンドが生成する結果の合成として）

ユーザビリティテストについて考えていましたが、疑問が残りました。以下では、それを例示してみます。

例を作ってみましょう。

私のライブラリが2つのコマンドで構成されていると仮定します。

  1. computeRectangleArea(B, H)は、長方形の面積を計算します
  2. computeTriangleArea(B, H)は、三角形の面積を計算します

ユーザビリティテストを実行するとしたら、次のようになります。

  1. ユースケースを定義します（例：長方形の領域を計算します
  2. このようなユースケースの目標を定義します。たとえば、height = 8およびbase = 3を持つ長方形Rの面積を計算します
  3. ゴールの実行に必要な一連のアクションを定義します（この場合はcomputeRectangleArea(3,8)を呼び出すだけです）

この場合、ユーザーが実行するアクションの正しいシーケンス（1つだけです）を推測すると、ユーザビリティテストは成功します。それ以外の場合は、失敗率を上げています。

私の疑問

ユーザーに実際にこのライブラリを使用してユーザビリティテストを実行させる可能性はあると思いますが、私は心配しています：

  • ユースケースは非常に複雑になり、多くのステップ、多くのコマンドを記述して起動する必要があります
  • このような複雑な使用例は、ユーザーが正しいアクションとコマンドのシーケンスを推測できない可能性があるため、検証が難しい場合があり、これにより、失敗率が大幅に増加する可能性があります。

これは、ユーザーにそのようなソフトウェアライブラリを評価させる方法がわかりません。ライブラリは一連のユーザー要件に従って作成されており、テストして、最初に指定したユーザー要件をカバーしているかどうか、満足できるかどうか、改良が必要かどうかなどを確認する必要があります。 。しかし、ユーザビリティテストが実行できないのではないかと心配しています。

このエンドユーザー評価を実行する方法に関する提案はありますか？

ありがとう。

usabilityusability-testingevaluation
4
Eleanore

アプリケーションのユーザーはエンドユーザーですが、ライブラリの場合、ユーザーは開発者です。彼らとテストしてください。開発者にとって、これはすでに単体テストとして知られています。

1
John Doe IV

まず、コンソールアプリケーションはもちろん、あらゆるアプリケーションでユーザビリティ評価を試みているのは素晴らしいことです。

開発者の考え方にとらわれないように、これらを「ユースケース」と考えることは避けるべきだと思います。ユーザビリティテスト用に テストシナリオ を作成しようとしています。

あなたの疑問に答えましょう：

  • 「ユースケースは非常に複雑になる可能性があります」：はい、より複雑なアプリケーションでは、テストしているシナリオは非常に複雑になる可能性がありますが、意味のあることを行うソフトウェアは、ある程度の複雑さを持っています。飛行機のコックピットは人的要因の研究を受けており、それらは邪悪で複雑です。
  • 「ユーザーがアクションとコマンドの正しいシーケンスを推測できないのではないかと心配しています」：これが、ユーザビリティ評価を行う理由です。

だから私にとって、あなたの疑問はあなたが正しい方向に向かっていることを示しているだけであり、あなたはただ進む方法について注意する必要があるだけです。 目標、メジャー、metrics。これらは、テストシナリオの通知に役立ちます。

performance（ユーザーが何かを行うのにかかる時間）、知覚パフォーマンス（彼らが感じたそれをするのにかかった時間）、satisfaction、learnability、またはその他の要因。 [〜＃〜] sus [〜＃〜] のように、ソフトウェアの使いやすさの一般的な「スコア」を取得するためにすでに存在する「ツール」もありますが、より具体的な何か。あなたの結果をより信頼できるように、私は複数のタイプのデータ（定量的および定性的）を取得しようとします。

学習可能性に焦点を当てた目標は、「ユーザーが使用して10分後にドキュメントを確認する必要はほとんどない」でしょう。メジャーは「ドキュメントチェックの数」であり、そのためのメトリックは「カウントman <command>は、アプリケーションに manual page がある場合に使用します。その後、その目標に対処するテストシナリオを構築できます。

知覚されるパフォーマンスに焦点を当てた目標は、「ユーザーが妥当な時間内に形状の領域を見つけることができる」かもしれません。対策は、タスク後に与えられた質問への回答になります。「このタスクに予想以上に時間がかかったと感じましたか、それとも妥当な時間でしたか？」メトリックは、各回答の数です。注意：これらの質問は、正しく理解するのが難しい場合があり、ユーザーは、問題がある場合はすべて問題がないと言う傾向があります。通常、ユーザーの発言に耳を傾けるよりも、行動を観察するほうが良い。

マイナーに思えるが重要な最後の1つ：タスクシナリオでは、ユーザーがタスクを完了するのに役立つ言語を再利用しないでください。あなたが与えた使用例では、「長方形の面積を計算する」はコマンドcomputeRectangleAreaの一部です。ユースケースでは、タスクを完了するために必要な単語の3つをユーザーに提供します。 「この形状の高さと幅を指定し、その領域を見つける」のようなものを試してください。 Wordにはまだ「領域」という単語があり、ユーザーが図形が長方形であるかどうかを判断するための認識オーバーヘッドが増加しますが、これはより現実的なシナリオのように見え、コマンド全体を渡すことを避けます。

1
Michael