テスト計画

テストフェーズと各テストフェーズのスコープ定義

一般的には「単体テスト」「結合テスト」「総合テスト(システムテスト)」「運用テスト(ユーザーテスト)」のように分類する。要件定義フェーズで、「テストフェーズ」をどのように分割するかを決め、各テストフェーズで何を確認するかを定義する。

私がよくやる分割は以下の通り。

テストフェーズテスト内容インプットドキュメント
単体テスト各機能設計書どおりに製造されていることを確認する各機能設計書
結合テスト業務フロー通りに機能することを確認する業務フロー
システムテスト1外部システムとのIFを確認IF一覧、IF仕様書
システムテスト2性能検証非機能要件一覧
システムテスト3バックアップ、バックアップからリカバリ運用手順書?
データ移行テスト移行計画書、移行手順書
ユーザーテスト業務シナリオにそったテスト実施(ユーザーが実施)業務フロー

場合によっては、そもそもこの定義の確からしさの説明が求められることがある。

私の場合、ISO/IEC9126やISO/IEC25010を使って、ソフトウェアに求められる品質特性を、どのフェーズでどうやって担保していくかを説明する。

各テストの開始条件と終了条件の定義

次に各テストフェーズの開始条件と終了条件を定義する。

これを事前に定義しておかないと、PMOや外部の人間に説明するときに困る。

テストフェーズ開始条件終了条件
単体テスト機能の開発が完了している・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
結合テスト単体テストの完了条件を満たしている
・定義したテスト項目をすべて実行した
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
システムテスト1結合テストの完了条件を満たしている・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
システムテスト2結合テストの完了条件を満たしている・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
システムテスト3結合テストの完了条件を満たしている・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
データ移行テスト結合テストの完了条件を満たしている・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している
ユーザーテストシステムテストの完了条件を満たしている・定義したテスト項目をすべて実行した。
・起票された不具合改修がすべて完了し、再テストされている
・定義した以外の不具合が検知されていない。されている場合は、その発生原因分析と関連テストの実行が完了している

テストスケジュールの定義

ここまででテストフェーズの定義が終わったので、あとは各テストフェーズをスケジュールに落とし込む。

ただこの粒度の情報のままだと、何となくや、締め切りや他の工程に必要な期間の余りに当てはめるようなスケジュールになりがち。対策としてはテストに必要な作業の一覧をWBSとして定義して、WBSベースで人月を積み上げる。

障害管理プロセスの定義

障害が発生したとき、どのような動きをするかを事前に定義しておく。

このとき障害管理のプロセスがどの状態なのかがわかるように、ステータスも併せて定義しておく。

テスト体制の定義

小さなチームなら省略してもよいが、人数の大きなチームの場合、誰が何担当なのかを明確にするために、体制図を作っておく。

テスト期間中の情報連携方法を定義

テスト時だけではないが、定期的に情報共有は行う必要がある。
会議の種類、参加者、実施タイミング、目的を整理しておく。

コメント