しかし、私たちにとっては、コンソールとホットキーの両方が完全に理解可能で便利なインターフェイスです。
プラグインをプログラム用に作成できる場合、便利で拡張可能です。 設定でメッセージボックスの背景色を変更できる場合は、柔軟です。 通常のユーザーは、このような柔軟性から温かくも冷たくもありません;彼はプラグインを書くのではなく、自分のタスクを解決する必要があります。
以前は、試運転中にユーザーインターフェイスをテストしました（これは、当社に新しいバージョンがインストールされたときです）。 この方法には欠点がありました。
- ユーザーは製品についてコメントする時間がありません。 特に、機能ではなくプログラムの使いやすさに関する場合。
- インターフェイスがどれほど直感的かは明らかではありません。 もちろん、調査を実施することもできますが、通常は有益ではありません。
- コメントが遅すぎます。 開発者はそれらを修正する時間が少なくなります。
コリドーテストを使用して、これらの欠点に対処することにしました。 ここで、経験を共有したいと思います。
CTに関する推奨事項
実際に近いシナリオを準備します。 実際のデータを使用してシナリオを準備することが重要です。「テストドキュメント」ではなく、実際の名前で契約と行動を行い、システム内の実際のユーザーと組織構造です。 システムを突くだけなら、そのような効果はありません。
テスト中にスクリプトを調整します。 最初の2人のユーザーに問題がある場合は、スクリプトを変更します。 そのプロセスの中で、システムとの相互作用の新しい状況を思いつくことが直接可能です。
さまざまなユーザーでテストします。 私たちにとって、最も有用なフィードバックを提供した最も興味深いユーザーは、新規参入者であるか、システムに精通していないユーザーです。 彼らはまだ目をぼけさせておらず、以前のバージョンで作業することによる中毒もありません。 高齢者、特に開発者は、お気に入りのホットキーが機能しないという事実についてほとんどコメントを受け取りますが、これらのユーザーも無視できません。
プロセスから官僚主義を排除します。 社内のほとんどの人が15〜20分を割り当てる準備ができています。管理者や人の選択による厳しい承認は必要ありません。コミュニケーターに書き込み、時間を調整するだけで十分です。 ほとんど全員が問題なく応答します。 応答しませんでした-ドジャーの代わりに電話する人が常にいます。
被験者の数を制限します。 主な問題を見つけるには、さまざまなレベルのトレーニングと機能的責任を持つ8〜10人で十分です。 コリドーテストの1つの結果に従って、検出されたバグの数と各ユーザーの新しいバグの数を計算しました。 最新のユーザーはほとんど新しいことを言っていないことがわかります。
自然環境を取得します。 キーボード、モニター、システム、言語、その他の環境は、人々を邪魔したり邪魔したりしないように、標準的で使い慣れたものにする必要があります。
ベータ版でテストします。 生の製品のテストは正常です。 いくつかのバグが出ても怖くない。 スプリントの最後に廊下のテストを行います。 ここでは、ほとんどすべてが機能し、次のスプリントで何かをすばやく修正するか、分析して修正を計画する時間があります。
開発前にスクリプトを作成できます。スクリプトは、設計と計画（何を行う必要があるかを理解する）、およびテストとテストの開発中、およびデモの両方で役立ちます。
すべてを記録します。 問題だけでなく、問題のない問題も修正します。 これは、現在うまく機能しているものを台無しにしないために必要です。