結合テスト

単体テストで問題なく動作すると認められたプログラムをサブシステム単位に組合せて、要求された機能ごとに確認をする作業が結合テストです。
システム開発Ｖ字モデルでは、詳細設計に対応するテストとして結合テストが位置づけられていますので、詳細設計工程で定義された設計内容の動作確認を行なう作業となります。

結合テストでのチェックポイント

結合テストでは、システムに要求された機能要件が実現できているかについて、次の視点から検証します。

①③④は組合せの対象は異なりますが、組合せ相互間のインターフェースの確からしさを確認するものです。
①はプログラムとプログラムのインターフェースについて仕様上想定されるバリエーションを確認します。③はサブシステムとサブシステムのインターフェースについて、④は開発対象外となる外部システムとのインターフェースについての確認をするものです。

②はサブシステム全体(プログラムを結合した状態)として要求されている機能が実現できているかを確認する作業です。

テストの実施順序

プログラムの組合せ方としては、単体テストでの動作確認が終了したものから順に、というのが自然な方法です。

しかし、機能が多岐にわたり複雑な構造となるプログラムが存在し、それがシステムの中核となるような場合、それ以外のプログラムは単体テストまで終了しているのに、その中核となるプログラムは機能が複雑であるために単体テストが終了しないということが発生することがあり、そのため結合テストが開始できないという事態が発生する可能性があります。

そのようなケースでは、スタブ(下位プログラム)やドライバ(上位プログラム)といったインターフェース部分だけが動作する仮のプログラムを事前に作成しておき、それを使って結合テストを実施するという方法もあります。
※スタブとは、テスト対象のプログラムから呼び出されるプログラムのことで、ドライバとは、テスト対象のプログラムを呼び出すプログラムです。

結合テストのテスト設計

結合テストの試験項目は次の手順で決定し、試験要領(テスト仕様)書としてドキュメント化しておきます。

テストすべき機能の選定

結合テストは、要求された機能が実現できているかを確認する作業です。システム化する際に要求された機能を、基本仕様(外部設計)書と詳細仕様(内部設計)書から洗い出します。
まず、詳細仕様書を用いて、ユーザから要求されている機能を実現するために必要な内部処理を確認します。ある機能を実現するにあたり、いくつかのサブシステムを横断するような場合は、詳細仕様書からだけでは把握できない情報があるので、基本仕様書を確認する必要があります。

要求された機能を検証する際、サブシステムの範囲を逸脱してはいけないといった境界線を設けて、試験すべき内容を中途半端なものにしたりせず、機能の実装を確認する上で必要であれば、サブシステムをまたいだ形で試験設計をしましょう。

また、先行してテストを行なったＡというサブシステムで、サブシステムＢに連携する部分のテストを行なっていた場合、サブシステムＢのテスト設計でサブシステムＡに連携する部分を対象外としてしまうケースが見受けられます。テスト設計は必ず行ない、テストすべき項目をもれなく抽出した上でテスト実施の要否を判断するようにしてください。

テストケースの選定

ユーザから要求される機能では、一般的にイレギュラーの状態を想定せず、いわゆるノーマルな処理手順のみが語られます。ところが、実業務では入力データにも様々なバリエーションがあり、実行される処理も単純なものばかりではなく複雑な条件分岐が用意されているものですので、システムでは、それらすべての処理が実現されることが要求されます。

しかし、バリエーションのボリュームは無限大といっていいほど存在します。例えば、1つのプログラムに5か所の入力項目があり、それぞれ2種の入力パターンがあるとすると、組合せ数は32となります。そのようなプログラムが5本あるとすると、32の5乗で33,554,432の組合せとなってしまい、とてもすべてをテストできるようなボリュームではありません。

ところで、入力項目のすべてを無条件に組合せる必要があるかというと、そういうことはなく無意味なものや矛盾するような組合せも存在します。そこで、テストケースとして価値のあるものを選定する必要が出てきます。実業務を想定したマトリクス表を作成したり、オールペア法で絞り込んでみたり、あるいは発生頻度の高い組合せを抜き出したり、といったフィルターを用意します。
結合テストで、どの項目を組合せるべきかや、どの組合せパターンをテストとして採用するかは、プロジェクト計画時に定義された品質方針をふまえて決定するようにしてください。

試験要領書の作成

結合テストの試験項目(試験手順)は必ずドキュメント化し、試験内容がわかるように整理しておきます。
結合テスト以降の工程である総合テストや運用テスト、および、稼働した後で障害が発生した時、結合テストで実行したテストケースとの差異点を明らかにすることができ、障害の発生要因を特定しやすくなります。

結合テストの試験結果分析

結合テスト実施時に誤りが検出された場合は、その発生原因と発生傾向を分析した情報を記述した試験成績書を作成しましょう。

プログラムの単体テストでは、プログラムの製作を他部門や外注先に依頼することから、試験成績書の作成を指示し提出させていると思いますが、結合テストからはSEの作業となるため、試験要領書は準備しても試験成績書は作成しないケースも多いかと思います。

プログラムの修正をPEに依頼する時には、プログラム不具合報告書は作成せざるを得ないものとなりますが、不具合の検出数が増加するにつれプログラム修正後の動作確認におわれることになり、それ以外のことには手が回らなくなり、分析作業がないがしろにされてしまっているのではないでしょうか。
しかし、検出数が多ければ多いほど、分析が必要となります。発生原因や傾向の分析をしないまま場当たり的な対処しかしていないと、いつまでたっても収束しないということになりかねません。

「製作ミス」があったからそのミスを修正した、「仕様齟齬」があったから仕様を再説明した、というだけでは、同じような誤りがまた見つかるとまた同じような対処をただ繰返すだけとなり、そういう不毛な作業に対しては「モグラたたき」という名前が付けられています。
もし「製作ミス」や「仕様齟齬」の発生要因が、「仕様書の記述に不明瞭な点があった」ということであれば、仕様書に同じ様に不明瞭な記述が無いかをチェックすることで誤りの再発を事前に防止することができます。
誤りが発生した際の効果的な対策というのは、「発生に紐付く根本的な原因を見つけ出して、それを解消することにより再発を防止できる」ということを見つけることです。

誤りの発生傾向を見極めることでウィークポイントを浮かび上がらせ、そこにプロジェクトのパワーを集中させることで品質確保という成果を導き出します。

品質メトリクス

品質指標(メトリクス)の一つに誤り検出率というものがあります。それは「システム開発規模あたりの検出件数」という定義になっています。
「人間はミスをする」という前提から用意されている指標で、設計や製作で作り込まれた誤りを試験で検出する際の目標値という意味合いで使われています。

結合テストにおいて、いくつかの誤りは検出されるべきものであり、もし検出数が目標値より少ない場合はテスト品質(試験項目内容)を疑う、という対処が求められます。
適切な件数の誤りが検出されており、その原因分析をした上で対策がすべて実施済である、というのが結合テスト工程の評価としては望ましい結果となります。