テスト計画書とは何か。システム開発におけるテストの重要性を現役エンジニアが解説

1 テスト計画書とは？
2 テスト計画書に必要な要件とは？
3 まとめ

システム開発では、プログラムに不備が無いか、データの整合性が取れているかなど、必ずテストを実施し、レビューする必要があります。テストは、ソフトウェアの品質を検証するための重要なフェーズと言えるでしょう。

システムにはさまざまな機能が搭載されており、規模が大きくなるほど複雑になります。テストでは、各機能に問題が無いことを抜け漏れなく確認することが求められます。そのためテストを実施する前には、テスト計画を立てることが重要です。

この記事では、テスト計画の必要性や要件などについて紹介します。

テスト計画書とは？

テスト計画書とは、システム開発の際に実施するテストに関して、方向性や目的、注意点、スケジュールなどをまとめたものです。テストの指針となるため、重要な位置づけとなります。テスト計画書は、大きく分けると「全体テスト計画書」「個別テスト計画書」の2つです。

テスト計画書	内容
全体テスト計画書	テストを実施する際のテストレベルを定義します。テストレベルとは、どのような単位でテストを行うかを取り決めたものです。またテストを実施する上で必要な人員や環境の取り決めや、テスト実施時の品質、進捗確認方法、不具合が出た場合の手順なども定義します。
個別テスト計画書	運用テスト、システムテスト、結合テスト、単体テストなど、各テストレベルで実施する内容をまとめたものです。個別テスト計画書では、それぞれのテストレベルにおいて対象とする機能を明確にします。また正常系のテスト、異常系のテスト、境界値、事象の組み合わせ、処理速度、セキュリティなどのテスト時の観点についても取り決めを行います。

システムには多数の機能が含まれており、思い付きでテストをしてもすべてを網羅することができません。いくつかのテストレベルに分けて実施することが必要です。各テストレベルでは、それぞれ目的とテスト範囲が異なります。すべてを実施することで不具合を抽出するだけでなく、仕様の漏れや抜けもチェックすることが可能です。

テストレベル	内容
単体テスト	機能単体や画面単体など、それぞれのプログラムの正常動作を検証します。プログラムを構成するユニットやモジュールと呼ばれる比較的小さな単位が対象です。メソッドや関数といったものがユニットやモジュールになります。
結合テスト	プログラムを結合したり組み合わせたりした場合、正常動作を検証します。単体テストが完了した後に実施するため、ユニットやモジュールの品質は保証済みです。結合テストでは、ユニットやモジュールを結合させた場合の動作を検証します。
システムテスト	システム全体が正常に動作するか、仕様に一致しているかなどを検証します。ソフトウェアを構築した後に実施するテストです。要求された性能や機能に問題がないかなどを確認します。
運用テスト	本番と同じ稼働環境において、正常動作を検証します。システム開発が一通り完了した後に実施するテストが運用テストです。実際に使用される環境下で、問題なく動作するかどうかを確認します。運用部門がテストを担当し、システム開発会社はサポート役に回ります。

テスト計画書に必要な要件とは？

テスト計画書は、開発するシステムの品質を確認できるような内容で作成します。そのため、さまざまな要素を取り決めておくことが必要です。

テスト範囲

テスト対象となるプログラムやソフトウェア、ハードウェアなどの範囲を決めます。テスト範囲を明確にしていない場合、テスト漏れが発生してしまうことが考えられます。例えばプログラムに不具合があり、その部分のテストが漏れていた場合、リリースしてから問題が発覚するため、大きな問題になることが考えられます。

各テストレベルでテストの範囲を明確にしておくことが大切です。

テスト粒度・テスト定義

各テストレベルで実施するテスト内容の粒度や定義を、明確にしておくことが必要です。複数のメンバーでテストを実施する場合、粒度や定義を決めていないと品質にばらつきが出てしまいます。その結果、再度テストをやり直すという事態に陥ってしまうことも考えられるでしょう。

またシステム特性によっても、粒度や定義が変わってきます。例えば扱うデータの量が少ないシステムにおいては、レスポンス時間などの性能面を考慮する必要はほとんどありません。しかし扱うデータの量が多いシステムの場合は、性能面が重要となります。

このようにシステム特性によって重視すべき点が異なるため、粒度や定義を明確に取り決めておくことが大切です。

テスト環境

テストを実施する環境について、明確にしておく必要があります。例えば、テストで使うサーバの構成や性能などです。ネットワークの情報に関しても明確にする必要があります。開発するシステムが外部のサービスやシステムを利用する場合、利用する時期や必要なライセンス数も取り決めておくことが重要です。

またテストごとに環境が異なる場合もあります。例えば通信負荷テストを行う場合は、負荷が発生しやすい環境の構築が必要です。

テスト終了の判断基準

どのようなテストを実施し、どのような状態になれば終了とするのかを決めておく必要があります。終了の基準や合格、不合格の基準などです。これらの基準を取り決めておかないと、ソフトウェアの品質がテスト担当者によって異なってしまいます。納品後に不具合が出ると大問題に発展することもあるため、判断基準は重要と言えるでしょう。

またメンバーのリソースやスケジュールなどで、テストが不合格になってしまう場合もあります。そのような場合を見越して、テスト結果を許容する条件も明確にしておく方が良いでしょう。

モニタリング

テストの進捗状況や不具合の検出率、欠陥の混入率など、実施中のテストに関して評価できるようにモニタリングの取り決めも大切です。モニタリングによって、テストが正しく遂行されているかどうかが判断できます。もしテストの内容に問題があった場合は、対策を施すことが可能になるためです。問題を抱えたままテストを進めてしまうと、正しい検証ができなくなります。後戻り作業の要因にもつながるため、テスト状況のモニタリングは重要と言えるでしょう。

成果物

テストフェーズで作成する成果物について、取り決めます。テストケース、テストデータ、不具合リスト、計測データ、進捗報告、品質報告、サマリーレポート、テスト計画書などです。それぞれの成果物に関して、作成フェーズや作成時期、担当者などを割り振ります。またテストが完了した場合には、完了したことを報告するためのテスト完了報告書も必要です。

トレーニング研修

テストを実施する上で必要となる知識や技能について、トレーニングが必要な場合はトレーニング計画を記載します。テストを担当するメンバーの保有している知識やスキルから勘案して、トレーニングの内容を決定することが必要です。適切なトレーニングが行われていないと、テスト結果の信憑性が疑われてしまいます。十分な知識と技能が備わった状態でテストを実施することが大切です。