機能テスト
機能テストは、合意された要件に従ってソリューションが実行されているかどうかを判断する場合に使用します。 機能テストは、システムが要求どおりに実行されており、必要な出力を提供することを確認するために使用します。
使用できる機能テストには以下が含まれます。
- 単体テスト
- 全般テスト
- ユーザー受け入れテスト (UAT)
- システム テスト/エンドツーエンド
- 統合テスト
単体テスト
単体テストでは、ソリューションの 1 つの要素が動作することを確認します。 たとえば、Microsoft Dynamics 365 Customer Insights - Journeys を実装している場合に、メールの作成に対して単体テストを実行します。 単体テストでは、以前に合意した仕様のとおりにメールの作成機能が動作することを確認します。
このシナリオでは、全体像のテストや完全なソリューションが機能するかどうかはテストしません。 また、メールを送信できるかどうかや、機能をメールに追加できるかどうかはテストしません。 単体テストでは、実際のメールの作成のみをテストします。 すべてのプロジェクト チーム メンバーは、カスタマイズ、構成、自動化、カスタム コードを構築する際に単体テストを実行する必要があります。
全般テスト
全般テストでは、ソリューションが要件を実装していることを確認するために、テスト担当者がほとんどのテストを行います。
ユーザー受け入れテスト
ユーザー受け入れテスト (UAT) では、ユーザーがすべてのテストを実行します。 テストはユーザー ストーリーに基づいて行います。 すべてのユーザー ストーリーに対応するようにソリューションが適切に作成されているかどうかを確認する必要があります。 ユーザーは一度に 1 つのユーザー ストーリーを確認し、それぞれのユーザー ストーリーがソリューションによって満たされていることを確認します。 ソリューションがユーザー ストーリーをサポートしていない場合、ソリューションは完了として受け入れられません。
システム テスト
システム テストは、プロセスに関与してこなかった人が実行する必要があります。 システム テストでは、システムを見直し、論理的な脆弱性が存在しないかどうかを確認します。 このタイプのテストでは、このプロジェクトの詳細を知らない人々にとってシステムが理にかなっているかどうかをテストできます。 テストの重要な手順は、システムが論理的であり、適切な方法で開発されているかどうかを判断することです。
システム テスト、つまりエンドツーエンド テストでは、複数のビジネス プロセスにわたる、完全に構築された環境内のソリューションを検証します。 通常、このテストでは、テストの対象となるすべてのプロセスを検証する必要があるため、テスト用データの設定により多くの手間がかかります。
統合テスト
統合テストでは、統合が機能するかどうかをテストします。 たとえば、Microsoft Dynamics 365 Finance と、信用調査を行う企業間の統合に関与しているエンタープライズ顧客と作業を行っている場合のシナリオを考えてみてください。 1 つのレコードを使用して、統合が機能し、予期されるデータが返され、適切な場所に格納されることをテストする必要があります。 ただし、エンタープライズ顧客の場合、統合を介して送信されるレコードは 1 件だけではなく、複数のレコードが 1 日に数百、または数千の単位で同時に送信されることが一般的です。
また、統合のストレス テストも実行する必要があります。 1 日に発生する通話の最大数を統合において処理できることを確認する必要があります。 さらに、それをどのように処理するかを判断できなかった場合の動作もテストする必要があります。 ストレス テストは、障害が通知されるかどうかや、統合で処理されなかったレコードが保存されるかどうかを確認する上で役立ちます。 目標は、障害が発生しないシステムを構築することですが、障害に対処できるシステムを確実に構築する必要があります。