開発工程の中の結合・総合テストの説明です。
１．V字モデルの勘違い
テストは、一般的には単体テスト、結合テスト、総合テストと呼ばれる工程に分けられます。たまにV字モデルというものを持ち出して、この工程の違いを説明する人がいますが、その説明はほとんどの場合、実態とずれています。
テストは、システムが自分たちの思ったように作られているかを確認する作業です。厄介なのが、この「自分たち」です。「自分たち」には、ユーザー部門、システム部門、元請けベンダー、再委託先のベンダー、様々な立場の「自分たち」がいます。テストの工程は、この「自分たち」の違いで大きく分けられます。
例えば製造工程までの責任範囲が以下のような場合、
①要件定義：事業会社のユーザー部門やシステム部門
②基本設計：元請けベンダー
③詳細設計と製造：再委託先ベンダー
テストは以下のような工程と責任範囲で分けられることが多いです。
①受入テスト：事業会社のユーザー部門やシステム部門
②総合テスト：元請けベンダー
③結合テストと単体テスト：再委託先ベンダー
これがいわゆるV字モデルです。V字モデルを持ち出して説明する人の多くが、例えば②の総合テストであれば、「総合テストでは基本設計書通りに作られていることを確認する」という説明をします。
でもこれは誤りです。なぜなら詳細設計書も基本設計書も要件定義書も書いてあること（書きたいこと）は同じで、表現方法がユーザーよりかシステムよりかで違うだけだからです。
２．テストの工程の意味
テストは大きくは、「プログラムのテストか、機能のテストか」と、「単体のテストか、結合のテストか」の計４パターンで分けられます。
プログラムのテストは、いわゆる「単体テスト」と呼ばれる工程で実施するものです。テストの最小単位は「モジュール」です。スタブやドライバといったダミーモジュールを使って、モジュール単体のテストやモジュール同士の結合テストを実施します。
機能のテストは、いわゆる「結合テスト」とか「総合テスト」と呼ばれる工程で実施するものです。テストの最小単位は、「画面」とか「帳票」とか「バッチを動かすシェル」とか、システムを使う人が意識するものです。この機能テストも画面や帳票単体のテストと、画面遷移や画面から帳票を出力したりといった結合テストの２種類があります。
つまりテストのパターンは、テストの最小単位を「モジュール」とするのか「画面や帳票等」とするのか、テストの範囲を最小単位自体とするのか（「単体」）、最小単位同士とするのか（「結合」）の４パターンで分かれるのです。
そして一般的にモジュール単体のテストと、モジュール同士の結合テストは、「単体テスト」工程で実施し、画面や帳票単体のテストとそれら同士の結合テストは、「結合テスト」工程と「総合テスト」工程で実施します。
３．結合テストと総合テストの違い
結合テスト工程以降では、機能のテストを行います。前述のように機能のテストは、画面や帳票、バッチ等の単体のテストとそれらの結合テストの２種類しかありません。
ここで大切なことは、テスト範囲の定義です。一般的には「機能」や「サブシステム」といった括りで複数の画面や帳票、バッチをまとめます。本来は設計工程で定義するものですが、設計工程での定義とテスト工程での定義が、必ずしも一致しないことも多々あります。
機能テストの最小単位は画面や帳票等で、機能はそれらをまとめた「要件を実現できる最小単位」です。サブシステムは、それらの機能をまとめたもので、業務の括りでまとめたりします。
例えば稟議のワークフローシステムの場合、「稟議申請画面」や「稟議承認画面」、「稟議参照画面」、「稟議整理簿出力画面」、「稟議整理簿」、「未承認稟議の催促通知バッチ」、「稟議削除バッチ」、「稟議整理簿削除バッチ」、「ユーザーマスター登録画面」、「組織マスター登録画面」といったものがテストの最小単位になります。
この稟議申請画面と稟議承認画面を「稟議決裁機能」、稟議参照画面、稟議整理簿出力画面と稟議整理簿、未承認稟議の催促通知バッチを「稟議管理機能」、稟議削除バッチと稟議整理簿削除バッチを「メンテナンス機能」、ユーザーマスター登録画面と組織マスター登録画面を「マスター管理機能」といった機能で括ります。
さらにこの機能を、稟議決裁機能と稟議管理機能は「稟議サブシステム」、マスター管理機能とメンテナンス機能は「管理サブシステム」といったサブシステムで括ります。
一般的には、このサブシステム内の結合テストを「結合テスト」工程で実施し、サブシステム間の結合テストを「総合テスト」工程で実施します。
冒頭の責任範囲の例でいうと、再委託先ベンダーは、サブシステム内で完結するテストまでが責任範囲で、元請けベンダーはサブシステム間のテストが責任範囲となります。
４．なぜテストの工程を分けるのか？
理由は二つあります。一つは立場の違いによるものです。それぞれの立場の責任範囲でテストをするため、それぞれの立場ごとにテストの工程を分けます。
そしてもう一つの理由が本質的なもので、「割り切り」のためです。
結合テストは、対象範囲が広くなればなるほどテストの数が膨大になります。
例えば、稟議申請の入力パターン（機密区分の違いや決裁者の違いなど）が１０パターンあり、承認のパターン（承認、差し戻し、否認など）が５パターンあった場合、申請画面と承認画面の結合テストは、５０パターンあります。さらにそれらを参照画面で４パターンの人（申請者、承認者、同一部署、別部署）が見る場合、２００パターンのテストとなります。
でも例えば「承認された社外秘の稟議」と「否認された社外秘の稟議」、「承認された厳秘の稟議」と「否認された厳秘の稟議」を参照する際、これらの違いは社外秘か厳秘、承認か否認なので、「承認された社外秘の稟議」と「否認された厳秘の稟議」の２種類を参照すれば、テストとしては十分です。もちろんこの２つがOKでも、「承認された厳秘の稟議」の参照がNGとなる可能性はゼロではないのですが、費用対効果の観点で、テストをしていなくても恐らくOKだろうと割り切るのです。
具体的なテストケースとしては、以下のように全２００ケースのうち、実際の稟議参照のテストは５２ケース程度に絞ることができます。
この割り切り度合いが、機能内の結合テスト、サブシステム内機能間の結合テスト、サブシステム間の結合テストと範囲が広くなるにつれて（結合度が弱くなると表現します）、大きくなります。
先ほどの例でいうと、稟議申請と承認の結合テストは、どちらも稟議決裁機能内の結合テストなので、全パターンをテストして、これらを参照するテストは、稟議決裁機能と稟議管理機能の機能間のテストなので、必要な要素の組み合わせテストに絞ってテストをします。
申請した稟議を削除するといった「稟議サブシステム」と「管理サブシステム」といったサブシステム間の結合テストの場合には、さらに大量にあるテストの組み合わせの中から、実際にテストする組み合わせを大幅に絞り込むことになります。
役割分担の例でいえば、再委託先のベンダーは、稟議申請をして承認をして稟議整理簿を出力するといった流れまでは品質を担保して、元請けベンダーは稟議申請をして承認をして稟議整理簿を出力して、一定期間経過後に稟議を削除したり、稟議整理簿を削除したりといった流れまでの品質を担保します。
これが元請けベンダーがテストをする際、申請した稟議を承認できないといったようなバグが見つかると、再委託先ベンダーに強化テストを要請したりして、本来やろうと思っていた稟議の削除等のテストが進まなくなり、総合テストの進捗が遅延することになります。
５．重要なこと
繰り返しになりますが、結合テストと総合テストの本質的な違いはありません。
重要なことは、機能やサブシステムを定義し、元請けベンダーや再委託先ベンダーの責任範囲をどこまでのテスト範囲にするかを明確にすることです。
結合テストは、誰がどの範囲のテストをすることなのか、総合テストは誰がどの範囲のテストをすることなのか、といったテスト全体の工程定義を全体テスト計画というもので、テストを開始する前に明確化します。
契約時点でおおよそのことは決めていますが、開発が進まないと具体的な画面や帳票といったテストの最小単位が決まらないので、通常は製造工程に入った頃に全体テスト計画で、テスト工程をいくつに分けて、それぞれの工程の範囲を決めることになります。
ここでしっかり定義ができないと、テストの網羅性が担保できず、テストの不足が発生することになります。
先ほどの例でいうと、結合テストは再委託先が実施し、テスト範囲はサブシステム内の結合テストまで。総合テストは元請けベンダーが実施し、テスト範囲はサブシステム間の結合テスト、といった責任分担にしたとします。
このとき機能の定義が曖昧だと、再委託先は「稟議削除バッチ」が「稟議申請画面」とは別サブシステムと思い、この２機能の結合テストを実施せず、元請けベンダーはこの２機能を同一サブシステムだと思い再委託先がテスト済みと思い自分たちではテストを実施しない、ということが起こりえます。
結合テストは××設計書のとおりに作られているかを確認し、総合テストは△△設計書のとおりに作られているかを確認する、といった考えとは根本が違います。
定義ありきではなく、プロジェクトごとにテスト工程の定義を作ることがとても重要です。
参考までに私がPMとして携わった一番大きなプロジェクトは40億円の規模でしたが、この時にはテスト工程を以下のように定義しました。ちなみにプロジェクト体制は、元請けベンダー配下に再委託先が７社あり、７つのサブシステムをそれぞれの再委託先１社が担当していました。
①単体テスト（いわゆるプログラムテスト）：再委託先が実施
②機能内結合テスト（いわゆる画面単体のテスト）：再委託先が実施
③サブシステム内機能間結合テスト：再委託先が実施
④他システムとの連携テスト：元請けベンダーが実施
⑤サブシステム間結合テスト（いわゆる総合テスト）：元請けベンダーが実施
⑥システムテスト１（いわゆる受入テスト）：発注者のシステム開発部門が実施
⑦システムテスト２（他システム含めた事業会社のシステム全体テスト）：発注者のシステム開発部門が実施
⑧運用テスト：発注者のシステム運用部門とユーザー部門が実施
６．テストは、たくさんやれば良いというものではない
このテストケースの絞り込みですが、最近は起こりえる全パターンをテストするベンダーが多いのが実情です。テストケースの絞り込みは、個人のスキルに依存するので、全ケースをテストした方が良いという主張です。
果たして、全ケースをテストすることと、ケースを絞ってテストをすること、どちらが品質が良いでしょうか？
必ずとは言いませんが、ケースを絞ってテストをする方が品質が良いです。
プロジェクトに与えられた予算、期間、要員には限りがあります。実施するテストケースの量が多いからといって、テスト期間を延長するということはありえません。
同じ期間でテストを実施する場合、当然、ケース数が少ない方が一つ一つのテストを丁寧に実施できます。逆にたくさんテストをすると、テストを実施することで精一杯になり、本来のバグを見つけるという目的を見失ってしまいます。
人間はルーティンワークに、いつまでも集中力を保つことができません。似たようなテストを繰り返すと、いつの間にか思考が停止してしまいます。
テストをしてエビデンスにはバグがはっきりと出ているのに、バグを見逃すということがあります。無駄に大量にテストを実施するプロジェクトでありがちなミスです。
ではテストを絞って、除外したケースにバグが潜んでいたら、どうすればいいでしょうか。
それは反省すればいいのです。きちんとロジカルにテストケースを絞ったのであれば、そのロジックに考慮不足の点があったはずです。その考慮不足の点を補って、追加テストをすればいいのです。ほとんどの場合、漏れたテストケースは業務全体で見ればレアケースなので、致命的なバグである可能性は非常に低いです。このロジカルにテストケースを絞って、考慮が漏れていた点があれば反省して次のプロジェクトに活かす、ということの繰り返しがスキルアップに繋がっていきます。
スキルの低い人は、このロジカルにテストケースを絞ることができないので、何も考えずに全ケースをテストしてしまい、いつまで経ってもスキルが向上せずに効率の悪い仕事を延々と続けていくのです。
もちろんこの考えは、人の命に関わるようなミッションクリティカルなシステムや、１００億円を超えるような規模のシステムには当てはまりません。プロジェクトの特性に合わせて、テストの仕方を変えていく必要があります。
【振り返り】
今回は結合・総合テストの説明でした。次回は受入テストの説明をしていきたいと思います。
①戦略・企画
②要求定義
③要件定義
④基本設計
⑤詳細設計
⑥製造
⑦単体テスト
⑧結合テスト
⑨総合テスト
⑩受入テスト
