テスト計画を作成する
キャンバス アプリの展開における次のステップはアプリのテストです。 このユニットでは、テストの実行方法の基本について説明します。 テスト計画に含めるべき 3 種類のテストについて考えてみましょう。
テストのタイプ
単体テスト
単体テストは、テストの最小のコンポーネントです。 アプリの特定の機能や特徴が正しく機能するかどうかを確認するために使用されます。
エンドツーエンド テスト
エンドツーエンド テストは、ソリューション全体が正常に実行されることを確認するために使用されます。 これは、すべての単体テストが正しく機能する場合でも、ユニット間の統合が失敗する可能性があるため重要です。 エンドツーエンド テストは、実際のビジネス プロセスのユース ケースに近いテスト シナリオに従って実行します。
ユーザー受け入れテスト
ユーザー受け入れテスト (UAT) は、アプリの作成者ではなく、ユーザーが行います。 このテストでは、作成者が作成した機能がユーザーの要件と一致していることが確認されます。
UAT を最大限に活用するためのヒントを次に示します。
実際のユーザーでテストします。
できるだけ、IT スキルのレベルがさまざまなユーザーを選択します。 これにより、さまざまなタイプのフィードバックを得ることができます。
ユーザーに指示を与えないでください。彼らがアプリを直観的に理解できるかどうかを見ましょう。
サポートなしでユーザーがアプリをナビゲートする様子を観察し、設計の改善が可能な部分を判断します。
ユーザーが画面の操作に行き詰まった場合は、ユーザーの期待がどのようなものであったかを尋ねます。
さまざまなデバイスでテストし、プラットフォームに関係なくテスト ケースが同じように動作することを確認します。
オフライン機能をテストします。理想的には、アプリでオンライン機能を使用する場合は、ユーザーの実際の環境または場所でアプリをテストします。
テキスト フィールドに一般的ではない文字を入力してみるなど、テスト ユーザーにアプリを「破壊」するよう求めます。
通常、ユーザーは「ハッピー パス」(すべてが完璧に進んだ場合にユーザーが辿るパス) をテストします。 また、経費精算書を送信する代わりに取り消したり、経費精算書を承認する代わりに却下するといったシナリオをテストするようユーザーに求めます。
ユーザーがソフトウェアのテストに詳しくない場合、どのようなフィードバックを求めているかを知らせます。 必ずテスト担当者が以下の点を説明するよう、"バグ" のテンプレートを用意すると役立つことがよくあります。
- 操作の正確な内容
- 何が起きたか
- どうなることを期待していたのか
- デバイスの種類やブラウザーなど、テスト環境に関する関連情報
ユーザーが仕様の変更を要求したり、他の機能を求めるのは自然なことであり、許容範囲です。 そのような要求は、優先順位を付けてアプリに組み込むことができるように、「機能要求の優先順位付け」で説明されているような機能リストに記録してください。
テスト ケースとテスト シナリオの作成
テストを計画するときは、Power Apps プロジェクトの計画フェーズや設計フェーズで明らかになった重要なシナリオを考慮します。
最初のステップとして、単体テストを作成します。 機能ごとに別々のテストを作成します。このテストは、次のように表に記録できます。
| テスト ケース番号 | テストの説明 | テスト対象の入力 | 期待される結果 | 結果 |
|---|---|---|---|---|
| 1-1 | フォームから注文の詳細を送信する | 注文番号 16516 | 注文が正常に送信される | |
| 1-2 | PDF が生成され、レコードに添付されていることを確認する | 該当なし | PDF ファイルが自動的に添付される | |
| 1-3 | メール通知がユーザーに送信されることを確認する | test@contoso.com | 指定された受信者がメールを受信する |
要約すると、計画が優れていればテストをより円滑に行うことができます。 目標は、テストの目的と適用範囲を説明して、技術的なレビューのプロセスを示し、機能の円滑なロールアウトを支援するテスト計画を作成することです。 テスト計画はユーザー受け入れテストの前に策定し、ロールアウトの前に必要な変更を追跡して実行する方法を組み込む必要があります。