テストを実施するにあたって、どのようなテスト観点を確認するか、事前に定義する必要があります。

テスト観点が定まらない限り、テストシナリオやテストケースが決まることはありません。

しかもテスト寒天はテスト工程によって変わってきます。


例えば、単体テストの場合は、単一の機能について分岐網羅や例外処理など、もっとも粒度の細かいテストを実施することになります。

一方で、総合テストの場合要件の確認になりますので、テストシナリオと言う考えが重要になります。

テストシナリオが漏れてしまうと要件を満たすことができているかを確認することができなくなるので、再度要件を正しく理解する必要があります。

また総合テストでは、実際の運用されるデータ件数を想定した性能テストや、障害時等、不測の事態に備えた運用手順書のテストを行ったりします。


このように、テスト計画書では、テスト観点を記載することで、各テスト工程におけるテスト範囲を定義します。

テストを実施するにあたり、要員等の計画は必須です。

テスト要因には大きく分けて2種類あります。1つ目はイメージがつきやすいのですが、テストを実際に実施する要員です。

これは同時に複数名作業する場合であっても、誰がどのテストを実施するか、また誰がどのテスト環境で実施するか、事前に計画しておくことで、テスト実施時にスムーズにテストを実施することができます。


2つ目ですが、進捗等の管理をする要員です。

これはプロジェクトリーダー等が担当しますが、テスト要員の進捗等を取りまとめ、プロジェクトマネージャーやユーザに進捗を報告する必要があります。

また不具合が発生した際には、不具合管理表で解決するまで管理する必要がありますが、その管理もプロジェクトリーダーの仕事です。


このような進捗や不具合管理などを行う人もまたテスト要員と呼ばれます。

テスト計画書において、重要なのが、何を持ってテスト工程を完了するかをあらかじめ定めておくことです。

よくある記載としては、テスト計画で定めたテストケースを全て完了させることや、不具合管理表が全てクローズとなっていることなどが挙げられます。

テスト工程が完了した際には、工程完了報告書と呼ばれるドキュメントで顧客に報告しますが、その際に皇帝完了条件は重要となる概念です。

あらかじめ計画時に定めておくことで認識齟齬を防ぐことができます。

テスト計画書を作成後は、テスト設計書を作成することになります。

テスト設計書は、テスト計画書で定めたテスト観点やテストシナリオに従って、具体的なテスト実施方法を記載します。

この時、テスト計画書を正しく定めておかないと、テスト設計書を正しく記載することができず、結果として正しいテストを実施することができません。

テストを実施する際は、テスト環境がどうなっているかを考えるのもまた大事です。

特に本番環境以外でテストを実施する場合は、本番環境との違いを明確化するためにテスト環境について正しく記載する必要がございます。


実際にテストを行った結果、想定と異なる結果が得られたときに、プログラムによるバグなのか、環境差異によるものなのかを正しく切り分ける必要があるのです。

結合テスト以降の場合は、テストシナリオを定義することが多いです。

テストシナリオとは、業務等を想定したパターンを一通り網羅するようなシナリオを指しております。

テストシナリオを作成するためには、要件定義書や基本設計書をインプットに、想定される業務について、学習した上で、それをシナリオに落とし込みます。


また、テストシナリオを定義しておくことで、要件について改めて整理することもできるので要件漏れを防ぐこともできます。

テスト計画書上でテストシナリオを作成したら、テスト設計書にてテストシナリオを実施するための手順や合格観点を記載することになります。

当然ですが、テスト工程はスケジュール管理が欠かせません。

定められた期間に対して、どのくらいのテストボリュームなのか、またテスト体制は何名体制なのか、事前に計画した上でテストを実施する必要があります。


もし正しく計画しないと無理なスケジュールを組んでしまうことになり、結果としてテストが間に合わないといったスケジュール遅延や、テスト実施がおろそかになったことによるテスト漏れを生じさせることもあるのです。


上記内容を防ぐためにテストスケジュールを定義する必要があるのです。