（前回からの続き）

　まずは，あるソフトハウスでの納品前の会話に耳を傾けてみましょう。

開発者●テストも全部終了し，納品の準備が完了しました。

上司●よし。残業すれば何とか間に合いそうだな。で，バグの状況は？

開発者●全部直しました。

上司●バグの収束状況を聞いているんだよ。

開発者●忙しかったもので，まだまとまっていません。納品が済んだら調べます。

上司●おいおい，それくらいちゃんとまとめておいてくれよ。じゃあ，制限事項になる部分や，テストが不十分で品質に心配がある部分などは残っているのか？

開発者●いや，特に問題ありません。

上司●このWebアプリケーションは一般ユーザー向けだったな。ブラウザの種類ごとのテストはどの程度やったんだ？

開発者●…テストに使ったブラウザは，Internet Explorer 6（IE6）だけです。

上司●IE6のみ？！ FireFoxやNetscapeでは動作確認してないのか？ まずいなあ。ところでそのIE6のマイナー・バージョンは？

開発者●開発用のパソコンを見ないとわかりませんが…。

上司●それくらいちゃんと調べろ。あと，納品はユーザーが使う他のブラウザでもテストしてからだ！

開発者●えーっ（いまさらバグ出たらどうすんの？ もうかんべんしてよ…）。

——このプロジェクトの開発者は，これから納品までの間，帰れない日々を続けることになりそうですね。こんなときは，テストが余計な作業に見えて仕方ないかもしれません。
　でもこれは，自業自得というものです。あらかじめテストする範囲を計画的に決めておかないと，このような事態になるのです。また，納品前には品質を判断する指標を用意しておくことも，テストの大事な仕事です。これらを怠るといつまでたっても納品後のクレームに悩まされることになってしまうでしょう。

ソフトウエア・テストは何のために行うのか？

　皆さんは，ソフトウエア・テストは何のために行うのだと思いますか。書籍「ソフトウェアテスト293の鉄則」＊1には，「つまるところ，テストする理由はただ一つしかない。重要な部分が動かない恐れがあるからだ」と書かれています。確かに，“人間は間違いを犯す生き物である”という言葉があるように，間違いをせずにソフトウエアを作るということは現実的には無理です。テスト工程にリリースしたプログラムのうち，だいたい100行に1〜3行は誤りが残ってしまうという報告もあります＊2。プログラミングより前工程の要件定義，設計にも同様のことが言えるでしょう。したがってテスト工程では，そのソフトウエアが意図した通りに動くのか，それとも動かないのかを，きちんと確認しなければなりません。

図1●ソフトウエア・テストは家計簿と似ている [画像のクリックで拡大表示]

　ソフトウエア・テストの定義は，専門家によっていろいろなものが提案されています。例えば，米国のテスト・コンサルタントであるRick D. Craig氏は，テストを「ソフトウエアの品質を測定して改善するための，テストウエアをエンジニアリングし使用しかつ保守しながら同時並行的に進めるライフサイクルプロセス」と定義しています＊3。この定義は，後述する「テストの全体像」を理解するうえではとてもよいと筆者は思うのですが，ちょっと読んだだけでは今ひとつわかりにくいかもしれません。そこで，ここではもう少し身近な例ということで，テストを「家計簿」にたとえて考えてみたいと思います（図1[拡大表示]）。

ソフトウエアのテストは
家計簿を付けることと似ている

　主婦向けの雑誌には「食費2万円実現のための家計簿テクニック」などというタイトルで，家計簿を付けて節約をするノウハウが掲載されていることがあります。筆者の家にもこのたぐいの雑誌が何冊かあるので，暇なときにパラパラとめくってみたりします。

　この「食費2万円実現のために家計簿を付ける」というのは，食費を2万円に抑えることができない“恐れ”があるので，家計簿を付けることで，食費の出費状況を“測定”する行為と言っていいでしょう。

　ソフトウエア・テストも家計簿と同じ理屈です。期待通りにソフトウエアが動かない“恐れ”があるので，ソフトウエア・テストをすることで「大丈夫もしくは大丈夫ではないこと」を“確認（測定）”するのがテストだからです。

　また，家計簿を付けても，その結果を「どうやって節約に結び付けるか」がないと，いつまでたってもただ記録しているだけになってしまいますよね。雑誌に書いてある通りに家計簿を付けても，月2万円の食費を実現することはできないことはおわかりでしょう。でも，家計簿の結果をベースに，夕飯のおかずの金額を調整するなど生活にフィードバックさせれば，月2万円という目標が達成できるようになるかもしれません。

　ソフトウエア・テストも一緒です。テストをしたから品質が上がる，わけではありません。テストした結果をバグ・レポートなどで開発チームに報告し，開発者がプログラムを修正することによってはじめて品質を向上できるようになるわけです。

　つまり，テストとは品質向上のための情報サービスなのです。開発中はバグ情報を，開発終了時にはマネージャや経営者（または顧客）にソフトウエアの品質を評価した情報を，というようにあらゆる人に有益な情報をもたらし，その情報が品質向上のための改善につながっていくことにこそ価値があるわけです。

家計簿/テストは余計な手間ではない

　とはいえ，家計簿を付け続けるのはなかなか大変な作業です。買い物をしたらレシートを捨てずに取っておかなければなりませんし，そのレシートを家計簿に転記する時間も確保しなければなりません。最近でしたら，家計簿ソフトを使う方もいるでしょうが，その場合もソフトを使いこなせるようになるまでには，それなりの学習時間が必要です。

　しかし，ここが肝心なところです。こういった導入や運用の手間を惜しむか惜しまないかが，（節約という）目標を達成できるか否かの分かれ道なのです。テストも一緒で，形だけのテストではなく，価値あるテストをするとなると，テストを計画/設計/保守していくエンジニアリングが必要です。また，テストを効率よく設計/実施するための技法やツールなどの技術も習得しなければなりません。これらの手間を惜しむと，結果的には納品後のバグ修正や顧客からの信頼回復などの不毛な手戻り作業が発生してしまうでしょう。

火が噴いてからでは手遅れ

　家計簿を付けるときは，その日に使ったお金をその日のうちに記録するのが基本です。お金が足りないと感じてから家計簿を付けだして，結果として「お金の使い方がダメだった」というのでは役に立ちません。問題が大きくならないうちに，日々の結果からその日の課題を家計にフィードバックすることが重要です。また，計画した金額で収まるようにするため，あらかじめ一定の金額を封筒に小分けしておくなどの技も雑誌には紹介されてます。

湯本 剛(ゆもと つよし) 株式会社豆蔵　ES事業部

　テストも，「プロジェクトが火を噴いてきたからテストに人を追加投入しよう」という考え方ではうまくいきません。バグだらけのソフトウエアをテストをしても，テスト工数がかさむだけです。テスト工数が計画以上にならないようにするためには，バグを早めに見つけなければなりません。開発の初期段階から設計内容をテストの視点でレビューし，テスト実施前にバグを予防できるように，開発と同時並行的に進めていくのが重要です。

　さて，以上のことをまとめてみましょう。

・テストとは情報サービスだ。品質向上のための改善につながることに価値がある
・テストのための手間を惜しまないのが成功の分かれ道
・早めにテストを行うことで，無駄にテストの工数を増やさない