ビルド前にデマンドをテスト: 結果を手動で提供します

関心があることを証明するためにプラットフォーム全体を構築したくなる誘惑にかられます。ただし、まだ流れがわかっていない場合、各画面には仮定が組み込まれています。手動テストではリスクが軽減されます。結果の単純なバージョンを提供し、エンドツーエンドのエクスペリエンスを観察します。

テストの約束を区切る

小さなタスク、参加者のプロフィール、およびその人が評価できる結果を選択してください。何が行われるか、何が行われないか、どのような情報が必要になるか、テストの終了方法を説明します。

自動化が存在するふりをしないでください。あなたが手動操縦士であることを説明してください。透明性は正直な観察を得るのに役立ち、プロセスがまだサポートしていない期待を生み出すことを避けます。

作業を実行し、手順を記録します

その人が何を送信したか、何を並べ替える必要があるか、どこで待機しているか、どの決定に人間のコンテキストが必要かに注目してください。繰り返されるタスクと例外をマークします。このシーケンスは、実際のプロセスの最初のマップです。

次に、何が最も役に立ったのか、何が疑問を引き起こしたのか、あなたの助けがなければその人は次に何をするだろうかと尋ねます。反応を観察された行動と比較してください。タスクを完了することは、通常、満足を宣言する以上のことを意味します。

製品になるに値するものを決定する

繰り返してルールを理解して確認できる部分のみを自動化します。それぞれのケースで異なる判断が必要な場合は、コーディングする前にさらに学習してください。誰もフローを終了しない場合は、提案を調査し、反射的に機能を追加しないでください。

手動テストは、偽装された安価なバージョンではありません。これは、それを構築する価値があるかどうか、どのように、誰にとって価値があるかを判断するための学習ツールです。

よくある質問

すぐにテストできる製品が必要ですか?

いいえ、重要なタスクを観察できる正直で安全なテストが必要です。ガイド付きの会話または手動の説明で十分な場合があります。

何人が参加する必要がありますか?

各ステップに従うのに十分な規模のグループを使用し、選択した対象者の関連する違いに気づくのに十分な多様性を備えたグループを使用します。

いつ自動化すべきでしょうか?

プロセスが繰り返されると、例外がマップされ、結果の品質をチェックする方法がわかります。

ビジネスをテストして改善するためのより実践的なアイデアを入手するには、Ímpetus ニュースレターを無料で購読してください。