システム開発プロジェクトで『テスト計画』は避けて通ることはできない。
システム開発では主に下記の3つのテスト工程がある。
・結合テスト
・総合テスト（システムテストとも呼ぶ）
テスト計画では、これらの各テスト工程で、どのようなことを実施するのかをざっくりと書くのだが、プロジェクト担当の経験が浅いと、テスト計画を考えるのに苦戦することだろう。
そころで今回は、システム開発プロジェクトの基本として、各テスト工程の違いや概要などについて簡単に説明していこうと思う。
目次
単体テスト・結合テスト・総合テストの違い
各テストの違いに悩むことがあるかもしれないが、ざっくり言うとテスト範囲が違う。
単体テストは単体機能、結合テストは機能間・他システム間、総合テストは構築したシステム全体（非機能も含む）
例えば、単体テストは画面1つ。
結合テストは、画面間のデータ連携だったり、画面からバッチを起動する場合のデータ連携だったり、システムAとシステムBのバッチ間連携だったり。
総合テストは、開発したシステム全体について要件を満足していることを検証する。
以降、各テストについて具体的に説明をしていこう。
単体テストの概要
テストの目的
「関数やメソッド単位にロジックの不具合を検出する」と定義されるのが一般的だが、どの単位で単位テストを実施するのかは、プロジェクト毎に定義すべきである。
つまり、単体テストを画面やバッチ機能単位で実施しても良い。
画面は複数の関数(メソッド)が組み合わさっているはずだが、その関数毎に単位テストをするという方法もある。
分かりやすくいえば、画面のボタン毎に動作を検証するという方法だ。
テストの観点
ロジックの条件分岐を網羅するテスト、いわゆるホワイトボックステストを実施する。
画面の表示のズレ（見た目）も合わせて確認することが多いだろう。
テストデータ
単体テストは開発環境にてテストを行う。
基本的にロジックを網羅するために、手作りのデータを用いる場合が多い。
とはいえ、１からデータを手作成するとなると大変なため、必要なデータを作る機能を先行して作成することになるだろう。
例えば、作業実績照会画面を作成するのであれば、作業実績を登録する機能を先行して作成することで、テストデータの作成負荷を減らすことができる。
内部結合テストと外部結合テストの違い
結合テストは、”内部結合テスト“と”外部結合テスト“に分かれる。
内部結合テストは、サブシステム内の機能連携を検証する。
外部結合テストは、サブシステム間の機能連携や、他システムとの機能連携を検証する。
規模の小さいプロジェクトであれば、サブシステム間の機能連携や、他システムとの機能連携が生じない場合もある。
場合によっては、外部結合テストは”不要”という判断となることもあるだろう。
内部結合テストの概要
テストの目的
サブシステム内の機能連携を検証する。
テストの観点
サブシステム内の機能間のインターフェースについて、不具合を検出する。
送信側で作成したデータを受信側の入力データとして、受信側の動作を検証する場合が多いだろう。
テストデータ
受信側の入力は、送信側の機能によって作成されたデータを利用する。
受信側の入力データを手作りしたり加工したりはしない。（イレギュラーな動作を検証する場合に、一部のデータを加工することはある）
外部結合テストの概要
テストの目的
サブシステム間や他システムとの機能連携を検証する。
テストの観点
サブシステム間、または他システム間のインターフェースについて、不具合を検出する。
内部結合テストと同様、送信側で作成したデータを受信側の入力データとして、受信側の動作を検証する場合が多い。
テストデータ
こちらも考え方は内部結合テストと同じ。
受信側の入力は、送信側の機能によって作成されたデータを利用する。
受信側の入力データを手作りしたり加工したりはしない。（イレギュラーな動作を検証する場合に、一部のデータを加工することはある）
総合テスト（システムテスト）の概要
テストの目的
総合テストは、システム開発会社（ベンダー）側の最終テスト。
開発したシステム全体が発注側の要求を満足していることを検証する。
テストの観点
要件定義書に基づいて、機能要件および非機能要件に関する不具合を検出する。
テストデータ
本番に近いデータを用いてテストを実施する。
例えば、本番環境からテスト環境にデータをコピーし、システムの上流工程から一連の機能を動作させながら、データを下流工程の機能につないでいく。
総合テスト（システムテスト）については、別記事にまとめたのでそちらをご覧いただきたい。
テストにおける注意点
実際のプロジェクトで注意した方がいい点を紹介する。
テストの注意点を上げるとキリがないかもしれないが、炎上プロジェクトにつながりかねないような特に重要な注意点を厳選して紹介する。
テストに必要なものを事前に洗い出そう
機能によっては、
・テストデータを作成するためのツール
・テスト結果を検証するためのツール
など、作成する機能以外でも作らなくてはいけないもが出てきたりする。
本来は、こういった機能は要件定義や基本設計フェーズで洗い出すべきであるが、検討が漏れる可能性がある。
テストを実施する直前に、ツールが必要だと気づいたときにはもう遅い。
テスト計画の段階であれば、まだスケジュールに余裕がある場合もあるので、事前に必要なツールがないかを検討しておくことをオススメしたい。
バグ（不具合）管理は徹底しよう
小さなプロジェクトではバグが放置される危険は低いかもしれないが、規模が大きくなってくるとバグが放置されてしまう可能性が高くなってしまう。
これは、担当者のミスというよりは、不具合管理（課題管理）に問題がある場合が多い。
（課題管理に問題があるプロジェクトは、かなりの確率で炎上プロジェクトになってしまう）
当たり前のことだが、不具合管理台帳への記載を忘れないようにすること、記載した不具合はクローズするまでフォローしていくことが重要だ。
なお、課題管理表は下記記事を参考にしてもらいたい。
テスト結果報告について
各テストでどんなことを検証したか、という点は、システム開発を発注した顧客に対してテスト結果を報告する際にも必要となる。
テスト結果報告では、主に下記のようなことを記載することが多い。
・テストケース数と不具合数
（不具合発生率）
・不具合の改修状況
・不具合の原因と傾向分析と対策
など
これらのテスト結果を報告し、「当システムは要件を満足していると考えております」と顧客に説明することになるのだ。
個人的には、”不具合の原因と傾向分析と対策”が大変だと感じる…
これは不具合を検出した際、”ロジックを直してテストしてOK”だけでなく、
・なぜその不具合が混入したのか？
・他に同様の不具合はなにのか？
といったことを分析して対策を取らなければならないからだ。
例えば、基本設計フェーズに根本的な原因があるようであれば、該当の設計書をチェックしなおすこともある。
テスト結果報告は、プロジェクトマネージャ（もしくはプロジェクトリーダー）がまとめることになるので、いずれは経験することになるだろう。
まとめ
単体テスト・結合テスト・システムテストについて、基本的な知識を紹介してきた。
単体テスト
単一機能の不具合を検出する
内部結合テスト
サブシステム内の機能連携による不具合を検出する
外部結合テスト
サブシステム間（もしくは他システム間）との機能連携による不具合を検出する
総合テスト
要件定義書に対して、構築したシステムの不備を検出する
システム開発プロジェクトを担当するうえで、上記のテスト範囲の知識は必修事項である。
当記事がプロジェクトを推進するうえで何かの役に立てれば幸いである。
テスト関係の記事はこちら。
いい勉強になりました。ありがとうございます。