導入
システムの設計後もソリューション アーキテクトの作業は続きます。 次のタスクは、システムが展開され、実際のユーザーによって使用されているのを確認することです。
テストおよび本番運用でのソリューション アーキテクトの役割
通常、ソリューション アーキテクトは、ソリューションがどのように機能するか、およびそのテストの際にテスト チームを導く方法について最も良く知る人々のうちの一人です。
ソリューション アーキテクトはテストで重要な役割を果たし、以下を行う必要があります。
- テストの成功を確認するため、テストの最後まで関わります。
- テスト チームによるすべてのコンポーネントと統合の適切なテストを確保するため、ソリューション アーキテクチャに関して、テスト チームの教育を支援します。
- テスト中、予行演習および本番運用後に発生する複雑な問題をトリアージします。
- 本番運用チームと共に本番運用戦略の計画と実施に参加します。
テストの概要
適切なテストは、プロジェクトの成功を確実にするために重要です。
メモ
テストは、最初のコンポーネントの構築から本番運用までの継続的な作業である必要があります。一度限りの大規模な演習ではありません。
テストは、要件を機能にマッピングするプロセス以上の役割を果たします。 これらのタイプのテストを構築して実施することは重要ですが、ソリューションには同様にテストが必要となる多くの側面があります。 テストで使用される測定基準を問わず、プロセスは似ています。
このテスト プロセスには、次のステップが含まれます。
計画 - 全体的なテスト戦略の確認、テスト計画の開発、および基準メトリックに対する必要な分析の実行を行います。 スコープの内外にある主要な業務シナリオを特定します。 そのステップをまだ完了していない場合、要件を文書化します。
準備 - 必要な環境、パフォーマンス テスト、ユーザー受け入れテストなどを設定します。 移行テストの前後に、移行用に受け取ったデータを確認します。 上位レベルのシステム要件を検証してから、必要なスクリプトを作成します。
実行 - テスト スクリプトの実行、結果の分析、潜在的なボトルネックの特定の後、不具合と動作の確認を行います。
レポート - レポート計画、結果、アクション プランの詳細な評価を準備します。
数種類のテスト
ソリューション アーキテクトは、プロジェクトに必要なテストの量とタイプに関するディスカッションに参加する必要があります。
Microsoft Power Platform でのテストの一般的なタイプには次が含まれます。
単体テスト - アプリ ビルダー、ビジネス アナリスト、業務コンサルタントや開発者が実行します。
機能テスト - 実装が要件を満たしていることを検証します。
受け入れテスト - 正式な承認を与えるためにユーザーが実行します。
回帰テスト - 変更されていない機能が引き続き正常に機能するかをテストします。通常は、システムの更新が発生した際に実行します。
統合テスト - 目標は、すべての統合システムが連携してうまく機能するかを確認することです。 統合テストでは、他のソースから統合されたサービスやデータを含めて、すべてがうまく連携していることを検証します。
パフォーマンス テスト - これらのテストは予想されるピーク時の負荷とピーク時のトランザクション ボリュームを使用して検証を行います。通常、本番運用前に自動化して実行します。
移行テスト - データの品質を確認するためにデータ移行の演習を行います。 これらのテストは、顧客データについて把握している対象分野の専門家と密接に協力して実施します。 これらの専門家は、データの移行と変換について把握している必要があり、移行したデータが適切なコンテキストで有効であることを確認できることが求められます。
障害復旧テスト - 機能しない障害復旧計画は役に立ちません。
本番運用テスト - 完全なソリューションと本番運用プロセスの予行演習。 通常、これらのテストは本番運用前に実行します。
すべてのタイプのテストが必須というわけではありません。プロジェクトの規模とスコープによって判断されます。
単体テスト
単体テストを使用して、アプリの特定の機能や特徴が正しく機能するかどうかを確認します。 通常、アプリの作成者と開発者が単体テストを実行します。 それぞれのチーム メンバーは、ハンドオフの前に自身の作業を確認する必要があります。
単体テストは推奨されますが、必須ではありません。 作業の開始時、またはソリューション内のコードが比較的少量の場合、ソリューションに含まれる機能の作成よりもテストの作成に時間がかかると感じることがあります。 単体テストのメリットが現実になり始めるのが、ソリューションが大規模で複雑になる場合、特にサーバー側の開発を伴う場合です。テスト フレームワークを使用してモック データまたは偽りのデータでローカルでのデバックを行う際に大きなメリットを感じることができます。
手動テストは、すべてのアプリ、ビジネス ルール、およびプラグインで行います。一部のテストは、Microsoft Power Apps Studio と Visual Studio を使用して自動化できます。 サーバー側開発でよく使われる単体テストのフレームワークは Fake Xrm Easy です。
ソリューション アーキテクトは、単体テストで使用するツールと使用の必要がある自動化のレベルを決定する必要があります。
統合テスト
ソリューション アーキテクトは、テスト チームが統合コンポーネントのテスト方法を理解するように支援する必要があります。
Microsoft Power Platform の利点の 1 つに強力な統合機能があります。 統合は、正しく機能するビジネス プロセスの実装の最も重要な要素の 1 つであり、全体的な導入に大きな影響を及ぼします。
ソリューション アーキテクトと顧客は、他の基幹業務アプリケーションとの統合に関わるテスト シナリオを確認し、エンドツーエンドのテスト シナリオが作成されていることを見極める必要があります。 通常、この確認のため、顧客は他のアプリケーション用テスト環境を計画する必要があります。
各統合には独自のテスト アプローチが存在する可能性があり、それを定義する必要があります。 テスト チームは、各統合シナリオをテストする方法について、早期の段階から決定する必要があります。 チームは、テストをサポートするように、必要な統合を構成できることを確認する必要があります。
統合テストの重要な側面は、統合に出入りするデータに焦点を絞ることです。 データ検証テストのセクションの説明の多くは、統合に関与するデータにも適用できます。
統合テストには他のシステムが関与する場合があるので、すべてのコンポーネントに対してテスト環境が使用されていることを確認する必要があります。 統合テストが実稼働システムにアクセスして、誤って実稼働データを変更することを避ける必要があります。 場合によっては、テスト シナリオでアプリケーション統合の構成オプションを操作し、テスト可能な状態を生み出す必要があります。 統合をオフにする機能があると、統合を呼び出さずにテストできます。
現在では、統合の構築プロセスへのアプローチがしやすくなり、それによってプロジェクト チームのより多くのユーザーがアクセスしやすくなります。 統合は、Power Apps キャンバス アプリケーションまたは Microsoft Power Automate フロー内で明確に表示されなくなることがよくあります。 これらの表示されない統合は、アプリケーションが別のソースからのサーフェス コネクタを使用しているために見過ごされることがよくあります。 計画では、他の統合と同様にこれらの統合について検討してから、それらに応じたテストを実施する必要があります。
ユーザー受け入れテスト
ユーザー受け入れテスト (UAT) は、正式な承認を付与し、システムの使いやすさをテストするためにユーザーによって実行されます。 通常、受け入れテストは、機能をロールアウトする前の最終チェックとして実行します。 このテストは、ユーザーが最初に要求した要件と作成者が作成した機能が一致していることの確認を目的としています。
UAT で良い結果を出すためのヒントを次に示します。
- 実際のユーザーを使用してテストします。
- IT スキルのレベルがさまざまなユーザーを選択します。 結果として、さまざまなフィードバックが得られます。
- ユーザーに指示を与えないでください。彼らがアプリを直観的に理解できるかどうかを見ましょう。
- サポートなしでユーザーがアプリをナビゲートする様子を観察し、設計の改善ができる部分を判断します。
- ユーザーが画面の操作に行き詰った場合は、ユーザーが何を期待しているのかを尋ねます。
- さまざまなデバイスで試し、テスト ケースが同じように動作することを確認します。
- 理想的には、アプリでオンライン機能を使用する場合は、ユーザーの実際の環境または場所でアプリをテストします。
- テキスト列に一般的ではない文字を入力してみるなど、ユーザーにアプリを「破壊」するよう求めます。
- 通常、ユーザーは「ハッピー パス」(すべてが完璧に進んだ場合にユーザーが辿るパス) をテストします。 また、経費精算書を送信する代わりに取り消したり、経費精算書を承認する代わりに却下するといったシナリオをテストするようユーザーに求めます。
ユーザーがテスト ソフトウェアに慣れていない場合があります。 あなたがどのようなタイプのフィードバックを求めているかをユーザーに伝えます。 多くの場合、バグのテンプレートを提供し、テスターが何をしていて、何が起こったか、何が起こることを期待していたか、およびテスト環境についての関連情報 (デバイスのタイプやブラウザーなど) を正確に説明できることが役に立ちます。
ソリューション アーキテクトはテスト中にユーザーが報告した問題のトリアージを支援する必要があります。
セキュリティ テスト
セキュリティ テストは、アプリケーションのセキュリティと、規制要件への準拠を確保するために重要です。 このテストには、アプリケーションが安全であることを確認するための脆弱性評価を含める必要があります。 また、各種のユーザーのセキュリティ コンテキストでのテストを含めて、適切なレベルのデータと機能が利用可能であることを確認する必要があります。
セキュリティ テストでは、アプリケーションのデータおよび機能にアクセスするためのアプリケーション内のセキュリティ モデルも確認する必要があります。 テストには、異なるロールおよびアクセス特性を持つさまざまなユーザーのシナリオを含めて、セキュリティ モデルがこれらすべてに対応できることを確認する必要があります。 セキュリティ モデル テストでは、過剰な共有や過小な共有が行われていないかどうかを確認する必要があります。 セキュリティ モデル テストに取り組む 1 つの方法は、主要なロール セットごとに専用のテスト ユーザー アカウントを作成することです。
ソリューション アーキテクトは、実行するセキュリティ テストのレベルの定義を支援する必要があります。