コンサルティング部ブログ

ちゃんと動くことをテストで確認する

若いときの話。
あるシステムの表示機能を開発していたが、テストをすると思った通りの結果が表示されず困った経験がある。多種パターンのテストを重ねても、一向に品質が安定しない。そんなある時、開発リーダより以下を聞かれて答え方がわからず困った事がある。

 「どうやってきちんとソースを書いた事を確認したのか」

当時、「とにかく動くものを早く作って、テストで動作を確認するのが、近道だ」と考えていたので、「どうやってきちんと・・・」と聞かれても「仕様書を見ながら、その実現方法を、私の仕様理解の通りにソースに反映した」としか答えられなかった。

それから何日かたって、リーダは次の質問をしてきた。

 「どうやって品質を確保した事を証明するつもりなのか」

当時の私はすかさず、「十分に動作確認を仕様書に基づいて実施する」と答えた。
そして、動作異常となる箇所が無いこと(すべてのテストが通ること)を確認し、私のテストは完了、次のテスト工程(結合テスト)へ引き渡された。

ドキドキで迎えた結合テスト初日、私の担当機能で障害が多発したのである。
関連機能とのインターフェイスミス(最大値の「誤解」)と判明したので、インターフェイスを再調整し、私のプログラムを修正することに。テスト結果に自信があったのでショックであった。
次の日、再び私の担当機能で障害が多発。調査の結果、先日の修正により「次の処理」に進んだが、条件により「次の処理」でも同様の問題が発生する事が判明した。(修正不十分)

リーダは予見していたのだろう。テストだけでは品質確保は難しいことを痛感した。本来は「関連機能との仕様のすり合わせ」を、テストよりも前に実施しておくべきであったのだ。

 「テストで見つかる障害は限られている。
              見つかりづらい障害も、いつかは表出する。」

のである。敵は手強い。

PIRO4DによるPixabayからの画像