ワークショップの準備
通常、テスト戦略のレビュー ワークショップは実施に 2 時間かかります。 この時間は、レビューに使用できる詳細レベルと、ソリューションの規模や複雑さによって異なります。 ソリューション アーキテクトは、実装チームのリーダーと協力して、レビューするソリューションの詳細やソリューション ブループリントのレビュー ワークショップから得られた調査結果に基づいて計画します。
テスト戦略のレビュー ワークショップの前に、参加者は、ワークショップの構成、前提条件、説明されるトピックの種類に関して、できる限り精通しておく必要があります。 ソリューション アーキテクトは、ワークショップを実施する前に、トピックや前提条件についてのアジェンダを提供します。
基本的には、テスト戦略のレビュー ワークショップはディスカッションです。オフライン モードで記入およびレビューできるアンケートは意図されていません。 前提条件を事前に定義して提示することはできますが、レビューで交わされるであろう会話の方向性をまとめて事前に示すことはできません。
ソリューション アーキテクトは、既存のプロジェクト成果物を確認して、ワークショップの準備を事前に行う必要があります。 次のプロジェクト成果物が役に立ちます。
- ソリューション ブループリント - プロジェクト スコープのコンテキストと、そのスコープを達成すると予想される上位レベルの設計を提供できます。
- 上位レベルのプロジェクト計画 - さまざまなタイプのテストが実施されるコンテキスト、依存関係、プロジェクトに対するテスト結果の影響を説明できます。
- テスト戦略ドキュメント - レビューする主要な領域について説明します。
- テスト計画 - 特定のテスト タイプのテスト戦略から作成されたテスト計画。たとえば、テスト ケース、リソース、レポートに関するより具体的な詳細を示すシステム統合テストや UAT には、別個のテスト計画が存在する場合があります。
財務と運用実装のテスト戦略 に関するこの技術解説など、テスト戦略の推奨手順を実装チームの関連するメンバーが調べることも役立ちます。 さらに、実装チームがワークショップに先立って既にある質問や懸念事項の一覧を送付した場合に、ディスカッションで焦点を当てることも役立ちます。
上記の一覧には、ディスカッションの骨組みを作るのに役立つドキュメントがすべて含まれているわけではありません。 たとえば、ソリューション アーキテクチャ図 (技術およびビジネス プロセス) と上位レベルのビジネス プロセスがソリューション ブループリントのレビュー ワークショップの一部としてまだ共有およびレビューされていない場合は、これらを用意することも役立ちます。
プロジェクトの早期にテスト戦略のレビュー ワークショップを実施した場合、ドキュメントがすべて完成していなかったり、内部で承認されていなかったりすることがありますが、これはドキュメントの共有やワークショップの実施の障壁とはなりません。 プロジェクト スコープを決定することと、ソリューションの検証方法に関する概念計画を作成することの方が重要です。
用意されたワークショップ テンプレート以外のさまざまな方法でプロジェクト情報を管理または追跡している場合や、さまざまなドキュメントや用語がプロジェクトで使用されている場合は、プロジェクトのアプローチと構造に合ったドキュメントを共有しても問題ありません。 通常、プロジェクト メンバーが情報をいつでも入手できるのであれば、形式はそれほど重要ではありません。 過去にリストした情報がドキュメント化されていない場合、または簡単にアクセスできない方法でドキュメント化されている場合は、関連するドキュメントを確実に生成すること優先する必要があります。
可能な限り図や視覚情報を使用して、上位レベルの概要を示すことをお勧めします。 これらの図、チャート、およびグラフは、チーム全体や役員と計画やデザインについてコミュニケーションを図る際のツールとして使用することができます。
注
テスト戦略のレビュー ワークショップは、プロジェクトの一環として実施されるすべての詳細なテスト ケースおよびすべてのテストを完全に網羅するレビューとなることは意図されていません。 前提条件は、実装チームが関連する概要を提供して主要な懸念事項を強調することと、ソリューション アーキテクトが問題の可能性がある領域を調査することです。 ソリューション アーキテクトが、追加の評価が必要な場合により詳細なワークショップを提案します。