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