アプリのテストに招待したテストユーザーの役割と、それらのユーザーとの通信をどのように処理しますか？
私たちのチームでは、このトピックについて少し喧嘩しています。詳細は説明せずに、次のことが起こりました。
新しいソーシャルネットワークを開発しており、現在アルファ段階にあります。私たちのアプリをテストするために、私たちは友人や知人のグループから100人以上の人々を招待しました。すべてのユーザーは、アプリがアルファ段階にあり、アプリをテストし、バグレポートと機能リクエストの形でフィードバックを提供する必要があるという前提で招待されました。
けんかを引き起こしたのは、チームメンバーの1人が固定ユーザーのタグ付けを使用して、機能していないと報告したユーザーにタグを付けるという事実でした。彼は「投稿」のコメントでユーザーにタグを付け、それが現在機能していることを確認するユーザーでタグを付け直しました。
一部のチームメンバーは、この相互作用が起こったことに腹を立てました。
テストユーザーの役割と、ユーザーに期待できること、期待できることは分かれています。コミュニケーションは片面ですか、それとも両面ですか？
一部のユーザーは、ユーザーがアプリをテストする必要があると考え、バグを発見したり機能が必要な場合は、アプリのフィードバックフォームを使用して報告します。そして、それは彼らがすることになっているすべてです。
私たちのチームの別の部分は、それは十分ではないと考えており、テストユーザーとの対話方法にはより積極的である必要があります。彼らが報告したバグが修正されているかどうか、または新しく実装された機能について彼らがどう思っているかを尋ねます。
このための良い習慣であるガイドラインはありますか？私たちの問題に役立つものは何も見つかりませんでした。
あなたの質問への答えは...それは異なります。
アルファステージテストの目的が、バグと高レベルのユーザビリティの問題をすばやく修正することである場合、反復フィードバックループに問題はありません。これにより、変更をより迅速に実装できるようになります。ただし、1人のユーザーが何か問題があると言ったり機能を要求したりする場合は、修正または投資する価値がない場合があることに注意してください。一般的に、ベストプラクティスは5〜12人のユーザーから同様の問題または機能の要求を聞くことです。
アルファステージテストの目的が、最も一般的なバグと高レベルのユーザビリティの問題、または最も頻繁な機能のリクエストに関する情報を収集することである場合は、一方的に残し、フィードバックを収集してからデータを分析する方が有益です。より頻繁または最も深刻な問題に時間とリソースを費やすため。
フィードバックを取得することは素晴らしい最初のステップです。この段階で、どの方法が最も有益であるかを判断する必要があります。
このためのより良いプロセスは、テストユーザーが達成しようとするタスクを定義し、各タスクの難易度を評価してもらい、タスクを完了することができたかどうかを判断することです。ブロックが発生した場合は、それが技術的なバグによるものか、混乱した経験によるものかを報告してもらいます。
この方法で問題に取り組むことで、ユーザーにバグスカベンジャーモードを許可するだけの場合と比較して、より実り多いやり取りが得られます。
これで、20人のユーザーがタスクに失敗し、すべてのユーザーと対話する必要がなくなりました。これで、サンプル全体が同様のタスクを実行し、関与する必要があるグループを絞り込むことができます。フィードバックプロセスで。つまり、テスターに同じタスクシーケンスを実行させるだけで、フィードバックループに必要なサンプルを減らしたり、新しいサンプルを作成したりできるように、テスト条件を標準化します。
なぜそれらのチームメンバーは、バグの報告や機能のリクエストにフォームを使用することだけをテスターに望んでいるのですか？バグが他のテスターに公開されることを望まないためですか？また、アプリがアルファ版から移行すると、このテスターのコホートはユーザーに変換されますか？これからどうするかを決めないと、これがどのように混乱を招く可能性があるかを理解できます。
ユーザーとの継続的なフィードバックループの維持の例は servoice で、ユーザーはバグやリクエストを投稿したり、他のユーザーが投稿した機能を確認したり、機能に投票したりできます。コミュニケーションをオープンに保つことの利点は、テスターがQAと同様に修正を検証できるようにすることです。答えは、テスターのこのグループをどのように関与させたいかによって異なります...
テストユーザーの役割は、ユーザーテストを実行する目的によって定義されます（これは、製品/サービスのステージと利用可能なリソースによって異なる可能性があるため）。明確で迅速なルールはありません。
ただし、テストの実行方法（メトリック/結果にとって重要な場合）と次のステップの不一致に関する問題を回避するために、定義された目的を持つことが重要です。
イベントの説明に基づいて、アプリケーションでテストする必要のあるさまざまなものがある可能性があります。したがって、ユーザーをグループ化して、各グループに異なるタイプのテストを実行させるか（あるテストが別のテストの結果に影響を与えると思われる場合）、またはグループ全体にすべてのテストを実行させることができます（数値が必要な場合）実施したテストの種類に応じて）。
ユーザーテストの最も重要な部分は、期待する結果を表示するようにプロセスを設定しないことを確認することです（つまり、不必要なバイアスを導入しないこと）。これが通常、プロセスの一貫性。ただし、全体像は、代表的なユーザーグループを使用して、設計プロセスで考えたり想定したりすることの間のギャップを埋めようとすることです。