若いときの話。
あるシステムの表示機能を開発していたが、テストをすると思った通りの結果が表示されず困った経験がある。多種パターンのテストを重ねても、一向に品質が安定しない。そんなある時、開発リーダより以下を聞かれて答え方がわからず困った事がある。
「どうやってきちんとソースを書いた事を確認したのか」
当時、「とにかく動くものを早く作って、テストで動作を確認するのが、近道だ」と考えていたので、「どうやってきちんと・・・」と聞かれても「仕様書を見ながら、その実現方法を、私の仕様理解の通りにソースに反映した」としか答えられなかった。
それから何日かたって、リーダは次の質問をしてきた。
「どうやって品質を確保した事を証明するつもりなのか」
当時の私はすかさず、「十分に動作確認を仕様書に基づいて実施する」と答えた。
そして、動作異常となる箇所が無いこと（すべてのテストが通ること）を確認し、私のテストは完了、次のテスト工程（結合テスト）へ引き渡された。
ドキドキで迎えた結合テスト初日、私の担当機能で障害が多発したのである。
関連機能とのインターフェイスミス（最大値の「誤解」）と判明したので、インターフェイスを再調整し、私のプログラムを修正することに。テスト結果に自信があったのでショックであった。
次の日、再び私の担当機能で障害が多発。調査の結果、先日の修正により「次の処理」に進んだが、条件により「次の処理」でも同様の問題が発生する事が判明した。（修正不十分）
リーダは予見していたのだろう。テストだけでは品質確保は難しいことを痛感した。本来は「関連機能との仕様のすり合わせ」を、テストよりも前に実施しておくべきであったのだ。
「テストで見つかる障害は限られている。
見つかりづらい障害も、いつかは表出する。」
のである。敵は手強い。