この記事は、[システムの品質は結合テストで決まる(1)]の続きです。
(1)を読んでいない人は、先にそちらを読んでください。
こうした仕様の劣化コピーは、どのようにして防げば良いのでしょうか？
設計書の品質向上、設計者とプログラマのコミュニケーション増加など、
「劣化」の度合いを小さくする手段はいくつか考えつきます。
しかし、どんなに努力したとしても人間は完璧になれません。
短期間で伝達を行う以上、度合いが多かれ少なかれ劣化コピーは発生してしまうのです。
ではどうするのでしょうか？
ここでようやく「結合テスト」が登場してきます。
プログラマには申し訳ない言い方ですが、
単体テストが終了した段階でも、プログラムのバグは取りきれていません。
（※詳しい話は[単体テストを信用するな]を参照）
残ったバグは主に仕様の劣化コピーが原因となっていることが多いので、
結合テストでそのバグを全て洗い出してやります。
つまり、事前に劣化を防ぎきれないので、後から補正を加えてやろうというわけです。
結合テストでは、単体テストで消化した項目もテスト対象となります。
（ただし、コネクションの取得のように内部ロジック的な部分は除く）
仕様の劣化コピーは、どの部分で発生したか特定できません。
全ての劣化に補正を加えるためには、やはり全機能をテストするしか無いのです。
そうなってくると結合テストの工数が肥大化します。
設計者は多くの機能を平行して担当することも多いため、
結合テストに時間を割けないことも多々あるようです。
そのため、結合テストを専門に行う「テスター」を雇うプロジェクトがあります。
しかし、私は全く賛成できません。
テスターは、テスト仕様書通りに動くことを確認して行くわけですが、
そのテスターに仕様を伝えるのは、テスト仕様書と短いミーティングのみです。
これではまた劣化コピーが起こってしまいます。
もちろん、テストを行わないよりはずっと良いでしょう。
しかし、設計者自身がテストを行うことに比べると、品質面では一枚落ちます。
やはり、仕様を完全に把握している設計者がテストを行わないといけません。
時間単価の高い設計者をテストに回すのは、プロジェクトの利益を考えると敬遠されがちです。
しかし品質を向上させたいなら、結合テストには惜しまず労力をつぎ込むべきなのです。
