システムの品質は結合テストで決まる(1)

前回は単体テストについて書きましたが、今回は次のフェーズである「結合テスト」について、
テストの目的や観点、テスト計画を立てる際の方針などを書いていきたいと思います。
(※本来は「機能内結合テスト(ITa)」「機能間結合テスト(ITb)」などに分類しますが、
今回はもっと大枠の話になるのでそこには触れません。)

結合テストの特徴は「設計者がテストを行う」点です。
この「設計者が行う」という点が最も重要であり、品質を決める重要な要素なのです。
なぜ設計者がテストを行うことに重要な意味があるのでしょう?
それを理解するために、まずプロジェクトの進め方について確認してみましょう。

プロジェクトには「設計」というフェーズがあります。
(外部設計、内部設計などに分けられていますが、ここでは説明省略)
設計者はユーザと仕様を話し合い、最終的に確定した事項を設計書としてまとめます。
この際、ユーザと設計者は打ち合わせを重ねるため、
仕様についてはお互いに同じ認識を持っていることになります。
(時々それが出来ないSEもいるので困ったものなのですが…。その話はまた後で。)

さて、ここまでは問題無いのです。
ユーザの望む仕様が全て設計者に伝わっているわけですからね。
問題なのは、この時点で「プログラマは仕様について何も知らない」という点です。
実際にプログラミングを実施してシステムを作るのはプログラマです。
彼らに仕様を伝えなくては、システムは出来ません。

設計者からプログラマへの仕様伝達は、主に設計書と短いミーティングによって行われます。
設計書には細かい仕様が書き連ねられているとはいえ、
設計者がユーザとの打ち合わせに使った時間に比べれば、だいぶ短い時間での伝達です。
また、どうしても文章には曖昧な記述が生まれるため、
プログラマが仕様を勘違いする危険性もあります。
こうして、設計者とプログラマの間で仕様の劣化コピーが行われ、
出来上がったプログラムが仕様通りに動かないという事態が発生するわけです。

--- [システムの品質は結合テストで決まる(2)]に続く ---
 

Webのことならお任せください。

俗に言う「ホームページ」が欲しい方はこちら。シンプルなサイトはもちろん、CMSの組み込みやショッピングサイトにも対応します。

多機能なWebサイトをご希望の方はこちら。予約管理機能や注文受付機能など、Webサイトにオリジナルの機能を追加します。

ご相談、お見積もりは下記よりお願いします。

お問い合わせ