新人技術者のためのロジカル・シンキング入門（7） ―― 「ひたすら流すだけのテスト」にさよなら

【1】納期前日に項目を作成していませんか？

　それもそのはず，Gさんがこの間までいた開発チームでは，テスト項目を用意して動作を確認することはほとんどなかったからです．

　そのチームでは，開発スケジュールがあまりにも短期間であったため，コーディングとデバッグに多くの時間を費やしていました．結局，納期を大幅にずれこんで，やっとのことで顧客にシステムを提供したため，テスト項目を用意してバグを見つける暇などなかったのです．実運用開始までの間，本番用のデータをひたすら流し込み，システムがおかしな動作をすればその都度直していたのでした．そのため仕様が明確でない部分も多くあり，目の前で起こった事象がバグなのか仕様なのかをめぐって，深夜にもめごとになったことも何度かありました．

　結局，「テスト項目」として納品したドキュメントは，納品日の前日に全員で急きょまとめ上げ，テスト日を工程上問題なさそうな日付に記したものだったのです．

　GさんはおずおずとPさんに尋ねました．「あの～，参考にしたいので，このチームでこれまで使っていたようなドキュメントを見せていただけませんか」．すると，リーダのPさんは表1を見せ，手始めにテスト項目をツリー上に分類してみるように伝えました．「項目分けを表にして整理することで，過不足なくテスト項目が整理できるから，みんなそうしている」ということです．「なるほど．これなら取りあえず何か思い付くかもしれない」．ほっとしたGさんは，与えられた時間，じっくりとテスト項目を考えてみることにしました．

表1　ツリー構造によるテスト・ケースの分類
ツリーを使ってテスト・ケースを分けるのはオーソドックスなやり方．分類を大きい方から小さい方へと分けていき，テストの漏れと重複がないようにしていく．問題はテスト・ケースの分け方である．

　仮に，読者のみなさんがリーダのPさんだとしたら，Gさんが提出してくるドキュメントにどのようなことを期待するでしょうか．

● ロジカル・ツリーの分け方

　Pさんが指示したようなテスト・ケースの分類はオーソドックスな方法であり，それ自体は至極まっとうなものです．とはいえ，実際にテスト・ケースを分類するとなると，経験の少ない人であればいろいろと悩むこともあるでしょう．たとえベテランと呼ばれているような人でも，初めて接するタイプのシステムであれば，なにかと工夫しなければならないことが生じることに気づくと思います．

　ここでは，組み込み開発で必要となりそうなテスト・ケースを，次の二つの点に焦点を当て，なるべく一般論（アプリケーションに依存しない）で解説します．

• モジュール単体のテスト・ケースの考え方
• 単体テストと結合テストのすみ分け