テスト戦略のレビュー ワークショップの概要

完了

Success by Design の目的は、お客様が Microsoft Dynamics 365 を正しく実装できるようにすることです。 テスト戦略のレビューの目的は次のとおりです。

• コミュニケーションと理解の促進 – テスト戦略のレビューは、テストの目的、テスト タイプ、テストのスコープと計画、ソリューションの検証手法についての実装チーム全体の全般的な理解を深める、テスト戦略についての会話を促すように設計されています。
• リスクと問題の特定 – 広範でありながら上位のレベルでテスト戦略を調べることにより、結果に悪影響を与えるアプローチにまつわる問題とリスクを特定できます。
• レコメンデーションの提供 – このワークショップでは、特定されたリスクに基づいて、リスクの管理と軽減に役立つレコメンデーションを提供します。

複雑なプロジェクトの場合、テスト戦略のレビュー ワークショップを対面で実施できます。その場合、通常は必要なすべてのトピックを 1 回のワークショップでカバーできます。 ワークショップは多くの場合リモートで行われます。

次のセクションでは、テスト戦略のレビュー ワークショップの最上位レベルの側面について説明し、各セクションで取り上げられている質問のタイプの例を示します。

全体的なテスト戦略

テスト戦略では、上位レベルの手法と計画を扱い、ソリューションが運用環境での使用目的に合致していることを検証します。 このトピックでは、以下のような質問について検討します。

• 文書化されたテスト戦略は用意されていますか?
• テスト戦略は、このプロジェクトのニーズや状況を反映していますか?
• テスト戦略は、プロジェクトに関連する言語、かつプロジェクトやビジネスの関連する関係者が理解できる言語で表現されていますか?

プロジェクト スコープとテスト スコープのマッピング

テストのスコープは、明らかにプロジェクトのスコープに依存しています。 このセクションでは、プロジェクト スコープがテスト スコープによってどの程度カバーされるかについて説明します。

このトピックでは、"プロジェクトの機能スコープ領域は、どのようにテストされ、どのテスト フェーズまたはテスト タイプの一部としてテストされる予定ですか?" という質問について考えます。

たとえば、次のようなスコープ領域について考えます。

• ビジネス プロセス
• ビジネス要件
• デザイン要件
• データ (機能上の用途、移行、インターフェイス、レポート/BI など)
• 地域
• カスタマイズされた領域
• プロセスの変更
• セキュリティ
• 規制による要件
• プロジェクトの目標

このトピックで考えるもう 1 つの質問は、"プロジェクトの非機能スコープ領域は、どのように、およびどのテスト フェーズまたはテスト タイプの一部としてテストされる予定ですか?" です。

たとえば、次のようなスコープ領域について考えます。

• パフォーマンス
• 使いやすさ
• 操作性
• メンテナンス性
• ディザスター リカバリー
• ビジネス継続性
• このプロジェクトに関連するその他の領域

上位レベルのテスト計画

テストはプロジェクト全体で実施されます。上位レベルのテスト計画では、ソリューションを段階的かつ包括的に検証するため、各種テスト タイプとテスト フェーズがどのような関連性で構築されているかを示す構造が提示されます。 このトピックでは、以下のような質問について検討します。

• 上位レベルのテスト計画はどのようにプロジェクト計画内に統合されていますか?
• テスト計画にテスト戦略は反映されていますか?
• すべてのテスト タイプとテスト フェーズがテスト計画に正確に反映されていますか?
• テスト計画では、プロジェクトの規模と複雑度に比例して、テストを実施するための十分な時間と労力が確保されていますか?
• テスト計画では、各種テスト領域に割り当てられた時間と労力が、ビジネスに生じるリスクに比例していることが示されていますか?

テスト フェーズとテスト タイプ

Dynamics 365 のようなビジネス アプリケーションでのテストは多角的であるため、テスト フェーズとテスト タイプはソリューションのさまざまな階層と側面の検証を表しています。 このセクションでは、主要なテスト フェーズおよびテスト タイプの重要なテスト定義とテスト管理属性の完全性について調べます。

次の表に、各テスト タイプで定義する必要がある領域の一覧を示します。

テスト - 主要な定義

テスト フェーズ/テスト タイプ	主要な目的	ソース ドキュメント	テスト範囲	開始基準	終了基準
テスト フェーズのタイトル (「統合テスト」や「ユーザー受け入れテスト」など) を入力するか、主要なテスト タイプ (「パフォーマンス テスト」や「モック カットオーバー」など) を入力します。	各テスト フェーズで達成される予定の主要な目標を入力します。	テスト ケースの内容と受け入れ基準 (つまり、テスト結果の検証基準となる定義は何か) を定義するために使用されるドキュメント タイプ/要件領域を挙げます。	このフェーズで検証する予定のプロジェクト スコープの領域を特定します。- エンド ツー エンドのビジネス プロセスと関連する構成 - 固有の機能 - 移行されるデータ	正式な実装を開始する準備ができていると判断するために、このテスト フェーズで満たす必要がある開始基準を定義します。	目的を達成したためこのフェーズを終了できると判断するために、このテスト フェーズでテスト結果が満たす必要がある終了基準を定義します。

テスト管理

テスト フェーズ/テスト タイプ	テスト準備	テスト実装	テスト レポート	テスト管理ツール	テストの所有権
テスト フェーズのタイトル (「統合テスト」や「ユーザー受け入れテスト」など) を入力するか、主要なテスト タイプ (「パフォーマンス テスト」や「モック カットオーバー」など) を入力します。	テスト開始基準を満たすことが期待されるテスト準備の簡単な説明 (テスト スクリプトの記述、データ要件、環境など)。	このテストの実装方法の簡単な説明 (テストを実行するロールや欠陥のライフ サイクル)。	テストの進行状況をレポートする方法、結果/品質を分析およびレポートする方法を定義します。たとえば次のとおりです。- 内部プロジェクト用途でのレポート - ビジネスの上級関係者へのレポート	テスト フレームワーク、テスト ケース、テスト結果の保存、確認、管理に使用するツールを決定します。 さらに、テスト ケースと要件/スコープのマッピングに使用するツールも検討します (Azure DevOps、Kira、Microsoft Excel など)。	このテストの結果に対して責任を持つ担当者を定義します。

上の表の情報は、すべてのテスト タイプに適用されます。 カバーされる可能性がある主要なテスト フェーズとテスト タイプは次のとおりです。

• 単体テスト
• 機能/プロセス テスト
• システム統合テスト
• エンド ツー エンド テスト
• ユーザー受け入れテスト (UAT)
• 回帰テスト

カバーされる可能性がある主要な非機能テスト タイプは次のとおりです。

• パフォーマンス テスト
• データ検証
• セキュリティ テスト

この一覧はすべてを網羅しているわけではなく、プロジェクトの性質によっては他のタイプのテストが関連する場合があります。たとえば、小売店舗での販売時点管理 (POS) テストや倉庫アプリケーションでのスキャン デバイス テストなどです。

上記のカテゴリで十分にカバーされない可能性がある特定のテスト タイプ/フェーズと特に関連性の高い他の質問は次のとおりです。

• 要件やビジネス シナリオから機能テスト ケースが定義されていますか?
• すべての機能モジュールが機能テストによってカバーされていますか?
• 機能テスト スクリプトはビジネス ユーザーによって検証されていますか?
• システム統合テスト戦略では、システム統合テストを実施するための、運用環境と同様のテスト環境の作成について説明されていますか?
• システム統合テストですべての参加システムを同期/再同期する方法が定義されていますか?
• エンド ツー エンドのテスト ケースは、各機能モジュールの所有者によって検証されていますか?
• エンド ツー エンドのテスト戦略では、使いやすさのテストが考慮されていますか?
• UAT の主要な関係者は特定されていますか?
• UAT 計画では、UAT フェーズにおける各関係者のロールが明確に文書化されていますか?
• UAT 時、必要なすべての関係者に対して明確なコミュニケーション計画をセットアップしましたか?
• 各メイン プロセスを分解してサブ プロセスを含めましたか?
• UAT でテスト シナリオに優先順位が付けられていますか?
• UAT テスト計画には適切な UAT テスト環境のプロビジョニングが含まれていますか?
• UAT 前にテスト担当者向けのユーザー トレーニングを計画していますか?
• 回帰テスト スイートを構成するコア テスト セットに対して適切な定義が確立されていますか?
• 回帰テストに対する最近の変更を (上位レベルで) 識別するためのプロセスは用意されていますか?
• テスト計画には回帰テストの自動化が含まれていますか?
• データ検証テストにはプロセスが定義されていますか?
• データ検証テストを実施するために適切なビジネス関係者は特定されていますか?
• 移行されたデータに対してエンド ツー エンド テストを実施する計画は用意されていますか?
• データ検証テストにはデータ調整レポートおよび計画が含まれていますか?
• セキュリティ テストの主要な領域は特定されていますか?
• テスト計画では、UAT またはシステム統合テストの前に、必要なすべてのセキュリティ ロールと権限を定義して割り当てる必要がありますか?
• セキュリティ テスト戦略には組織のセキュリティ要件が含まれていますか?

ツール

テストの計画、準備、実施、レポートには、かなりの管理が必要です。 かなりシンプルなプロジェクトでは、このプロセスがスプレッドシートを通じて管理されることがありますが、複雑なプロジェクトでは対応しきれず、追跡するのが難しくなる可能性があります。 ほとんどのプロジェクトでは、何らかの形式のタスク管理ソフトウェアが使用されます。 さらに、多くの組織では、自動化ツールを使用して、計画、テストの作成、テストの実行、テスト結果のレポートを行っています。 このトピックでは、以下のような質問について検討します。

• どのようなテスト管理ツールを使用し、どのような方法でテストとソース要件 (追跡マトリックス) をマッピングしますか?
• テスト ケースの ID とストレージの管理にどのテスト管理ツールを使用しますか?
• リソースの配賦の管理とテストのライフ サイクル全体 (テストの作成、テストの実行、テスト結果の照合、欠陥のログ記録、解決と再試行まで) の追跡にどのテスト管理ツールを使用しますか?
• テスト タイプの実行と結果の収集を自動化するためにどのツールを使用しますか?