PR

開発ドキュメントから洗い出す

 STEP1では、テスト対象となる候補の洗い出しをする。インプットとなるのは、要件定義書や設計書といったシステム開発で作成するドキュメントだ。テストの目的の1つは、ソフトウエアがドキュメント通りであるかどうかを確認すること。ドキュメントに記載されている業務や機能をテスト対象とすれば、少なくともこの目的に対しては漏れなく抽出できる。

 テスト計画の担当者は、インプットとなるドキュメントを特定しなければならない。プロジェクト全体計画書を参照して、開発プロジェクトで作成されるドキュメントと記載レベルの定義を確認しておこう。

 洗い出せるテスト対象の粒度は、インプットとするドキュメントによって変わってくる。多くの場合、テスト計画は要件定義フェーズか基本設計フェーズで実施する。実施するフェーズによって、完成しているドキュメントが異なる。一般に要件定義書は業務単位、基本設計書は機能(プロジェクトによっては画面や項目)単位でシステム化の内容を記載している。

 ECサイト刷新プロジェクトを例に考えてみよう。業務単位で洗い出すと「顧客管理業務、契約管理業務、商品管理業務、購入業務…」となる。機能単位で洗い出すと「顧客情報登録機能、顧客情報検索機能、新規契約登録機能…」となる。後者のうち顧客情報登録機能、顧客情報検索機能は、前者の顧客管理業務に含まれる。一般に業務のほうが機能より粒度が大きい。

 テスト計画の段階では、その時点で最新のドキュメントをインプットにテスト対象を洗い出せばいい。そして、開発プロジェクトの進捗に応じて、テスト対象を詳細化していく。

 テスト対象の詳細化の方法は以下の通り。開発工程が進めば、開発対象となる機能が明確になる。それに合わせて、テスト対象を具体化していく。例えば、要件定義フェーズでは業務レベルでテスト対象を決めておき、基本設計書が完成したタイミングで機能単位にテスト対象を決めるといった具合だ(図1)。

図1●業務と機能の対応関係
図1●業務と機能の対応関係
[画像のクリックで拡大表示]

 未確定となっている範囲はテスト計画に落とし込めない。これについては、どのタイミングで何が決まるのかを把握しておけばいい。決まった段階で明確にしていく。

 こうしたテスト計画の未確定部分は一覧表にしておき、責任を有する関係者に配布するとよい。仕様未確定であれば要件定義や設計の担当者、ユーザー側の要求未確定であればユーザー担当者に配布する。この際、検討期限を設定し、期日が到来するまで定期的に調整状況を確認する。

開発ドキュメントの外側にあるテスト対象

 続いて、開発ドキュメントにはないテスト対象を洗い出す。プロジェクトが機能追加や改修の場合に必要となる。要件定義書や基本設計書は開発のためのドキュメントであり、書かれているのはあくまでも開発対象だ。新規システムならば開発対象とテスト対象がイコールになるが、機能追加や改修では改修していない箇所もテスト対象として検討しなければならない。

 一般的なソフトウエアやシステムは、複数のプログラムの組み合わせで構成する。あるプログラムの1箇所を修正すると、その他の修正していないプログラムにも影響を及ぼす可能性がある。そのため、修正していないプログラムもテストを実施しないと、想定外の不具合を引き起こすリスクが残存する状態となる。こうしたリスクを回避するには、改修していない箇所のテストが欠かせない。

 具体的には、改修した機能と関連性のある機能を洗い出す。「改修した機能と同じデータを参照している」「改修した機能と同じ業務フローに含まれる」といった機能だ。これらは改修対象になっていなくても、改修した箇所から影響を受ける可能性がある。

 図2のシステム構成で「ピッキング」と「現場別債権管理」の機能が改修されたとしよう。改修箇所と直接関連する「在庫管理」や「現場別管理」といった業務に含まれる機能は、改修対象でなくてもテスト対象として検討する必要がある。「改修箇所とデータ連携している」といった機能も同様だ。

図2●改修箇所以外のテスト対象を洗い出す
図2●改修箇所以外のテスト対象を洗い出す
[画像のクリックで拡大表示]

 改修していない機能に対するテストも開発対象機能と同様、できるだけ網羅してテスト対象に挙げる。ただ、あまり手を広げすぎると、テスト期間内にテストが終わらない、テスト担当者をアサインできない、といった問題に直面する。そこで、次のSTEPでテスト対象に優先度を付与し、期間内で優先度の高い機能から網羅していくように計画を立てる。