みなさん、こんにちは。
テスト仕様書の作り方大公開の第6回です。ここまでの記事で、単体テスト（機能テスト）の設計ができるようになったと思います。しかしテストはここで終わるわけではなく、後には結合テスト・総合テストが控えています。今回と次回は新たなステージとして、結合テストの考え方と勘所を特別にお教えします。
前回記事はこちら
基本はＶ字モデル
結合テストをどう考えたらよいか？の前に、まず図-1をご覧ください。弊サイトの“テストに関するお役立ち資料集ダウンロード”にあります『ソフトウェアベンダー・SIerが知っておくべき 高品質なテストを実現するテスト入門ハンドブック』にも載せていますが、各開発工程に対応してテスト活動があるという『Ｖ字モデル』の考え方です。
お気づきのとおり、要件定義の正しさを総合テスト、外部設計の正しさを結合テスト、内部設計の正しさを単体テストでそれぞれ検証するようになっています。
“ビッグバン”などあり得ない
このように、開発するときは大雑把なところから漸次細かくしていくのに対し、テストするときは細かい部分から大きな領域に向かって統合していかなければなりません。個々のプログラムの品質が確保されていないまま統合しようとしてもあちこちで問題が発生して、にっちもさっちもいかなくなるのがオチです。（さらに困ったことに、どこに原因があるのか判別しにくいものなのです。）
例えば自動車を想像してみてください。自動車は約３万点の部品でできていると言われていますが、どれひとつとして重要でないものはありません。もしそれぞれの部品の品質が十分に保たれていなかったとしたら、それを組み立ててできた自動車はすぐに故障してしまうか、悪くすれば事故を起こしてしまうことになります。
俗に言う“ビッグバン結合”などあり得ません。このことは『ソフトウェア開発201の鉄則』（アラン．Ｍ．デービス著）の[原理119ビッグバン説はあてはまらない]の中で「不幸にして、この選択は、おそらくもとの日程にさらに６か月の遅れを与えることになるだけだ。単体及び統合テストを抜かすことで時間を節約することはできない。」と述べられています。
守備範囲を明確にする２つの理由
上述のＶ字モデルを実践するうえで最も重要なのは【スコープを決める】ということに尽きます。 なぜスコープを明確に決めておくことが重要なのか？それには２つの理由があるのです。
≪その１：スキマの防止≫ よくある失敗は「ここから先は結合でやるはず」「ここまでは単体でやってくれているはず」「この機能は対象外という認識だった」というような、勝手な思い込みによる“ポテンヒット”ではないでしょうか。 計画段階でスコープを明確にすることでそれぞれのテストの役割・位置付けをしっかり定義でき、各レベルのテストの間ですき間ができるのを防ぐことができます。
≪その２：テスト目的の明確化≫ また、テストのスコープを明確にすることは「何を」「どのように」確認したいのかということを突き詰めて考えることにつながります。 システムの機能を使って業務フローに則った業務が実施できることを確認したかったはずなのに、なぜか「使い勝手」とか「レスポンス」のような別の評価要素が混じってしまうといった恐れがなくなります。
スコープ決めは三次元
少しテスト計画の領域に入り込んでしまいますが、テストのスコープは次の３つの視点から考えるとよいでしょう。 ・タテ（機能）の範囲：フロント画面・管理画面・夜間バッチ・APIなど、機能一覧での対象範囲 ・ヨコ（連携）の範囲：サブシステム・社内外・機器接続性など、インターフェイスの対象範囲 ・奥行（目的）の範囲：機能確認・性能評価・セキュリティ診断など、求める品質特性の対象範囲
図-2は実際のプロジェクトで各レベルテストの位置づけをして全体像を考えた例です。 これはあくまで一つの例であって、決して「正解」ではありません。このような各段階のテスト（レベルテストと呼びます。）をどのように位置付け組合せ、それぞれどこまでを確認するかということはテスト計画の段階で決めるため、組織やプロジェクトによってまちまちです。
重要なことは「テストの守備範囲と役割を明確にしておくこと」です。これさえできていればテストの目的は必ず達成できます。逆に、これができていないと、いくら膨大なテストケースを積み上げたとしても的外れなテストとなり、徒労に終わってしまいます。
次回（最終回！）は結合テストのスコープと検証ポイントについてお話しします。お楽しみに。
ご愛読、ありがとうございました。
テストに関するお役立ち資料
テスト設計・仕様書の作り方に役立つ資料を多数ご用意しています。ぜひDLしてご利用下さい。
資料一覧は【こちら】
