基礎から学ぶソフトウエア・テスト（1）

今こそテストの基本技術を学ぼう！

2006.05.26

　これから6回にわたってソフトウエア・テストの基本について解説します。テストの基本を理解することは，品質の良いソフトウエアを作るための大切な一歩となるはずです。今回から第3回まではソフトウエア・テストに必要な技術について，第4回から第6回は品質分析やマネージメントについて解説します。

　まず，あるソフトハウスの上司と開発者の会話に耳を傾けてみましょう。

上司●設計は進んでいるか？

開発者●仕様が固まらず遅れ気味です。

上司●それは困ったなあ。対策は？

開発者●とりあえず今の仕様のままで設計を止めて，コーディングを開始します。幸いテスト工程を多めにとってあるので，徹底的にバグ出しをすれば品質は問題はないと思います。

　　　　　　～1週間後～

上司●コーディングは進んだか？

開発者●それが…，仕様変更など手戻りが多くて遅れ気味です。

上司●おいおい，まずいなあ。対策は？

開発者●テスト工程の一部をコーディングにまわして，そのぶんの工数で吸収します。

　　　　　　～1週間後～

上司●単体テストは進んだか？

開発者●やってますが…バグが予想以上に多くて…。

上司●かなり遅れているぞ。対策は？

開発者●基本的な部分のテストはやったので，ここらで切り上げて，後はシステム・テストで対応します。

　　　　　　～1週間後～

上司●システム・テストは終わったか？

開発者●それが実は…1人月の遅れが出ています…。

上司●…。

開発者●でも，他のプロジェクトから5人，1人0.2人月ごとに工数を補てんしてもらえれば，対応できます！

上司●…。

——いやはや，なんとも，これから，この開発プロジェクトはどうなってしまうのでしょう？ちょっとうすら寒い気がしますね。

　失敗に終わるソフトウエア開発プロジェクトにありがちなのが，要求分析や設計をおろそかにしてコーディングに走るパターンです。これを米国のソフトウエア技術者Steve McConnell氏は，「作ってから直す開発方式（code-and-fix development）」と命名しています＊1。この方式で，一番いいように使われてしまうのはソフトウエアのテスト工程です。まさに冒頭の会話はそのパターンと言えるでしょう。しかし，テスト工程をおろそかにしてしまうと，後でとんでもないしっぺ返しが待っています。

品質にまつわる問題はどんどん増えている

　最近，ソフトウエアの品質にまつわるトラブルが大きく報道されるようになりました。携帯電話が特定条件で発着信が不能になった＊2，ウイルス対策ソフトのパターン・ファイルのアップデートによりパソコンの動作が不安定になった＊3などのトラブルは記憶に新しいと思います。検索エンジンで「プログラムミス」「システム障害」「ソフトウエア不具合」などのキーワード検索をすると，その検索結果の件数にビックリするかもしれません。

　これらのトラブルの原因がすべて，「テスト工程をおろそかにしたことにある」とは言えないでしょう。とはいえ「十分なテストをしていれば，ある程度は防げた」ということは言えるのではないでしょうか。テストは，品質を守る大切な役割を担っています。しかし開発の現場では，「ちゃんと作ればテストなどいらない」「テストまで考えてる暇はない」「テストをしっかりやりたくてもノウハウがない」などの様々な理由で，二の次にされてしまっていることが多いのです。

テスト担当者はゴールキーパーである

　ソフトウエアの開発プロジェクトを，サッカーにたとえてみましょう。サッカーという競技は，各メンバーが自分たちの役割を果たしながら，かつメンバー間の不足を補いながらゴールに向かって攻めていきますよね。これは，ソフトウエアを開発していくときの，プロジェクト・マネージャ，設計者，プログラマの関係とよく似ています＊4。

　サッカーでは，メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この，サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。守りの専門職であるゴールキーパーがテスト担当です（図1[拡大表示]）。

　サッカーには，完全な防御方法はありません。点を入れられてしまう可能性は常にあるわけです。これと同じで，ソフトウエア・テストにもすべてのバグを発見する方法はありません。プログラムはいくらでも複雑に作ることができますし＊5，時間的，経済的な理由からテストをいつまでも続けることはできないからです。

　ここで，「完全にできないからがんばってもしょうがない」と結論付けたらそれまでです（この記事がいきなり終わってしまいます…）。大事なことは，不完全だからこそ，効果的な方法でテストする腕が必要だということなのです。

得点させない仕事はみんなの仕事

　無得点に押さえるには，自陣にボールを持ちこませないようにする——つまり，他のメンバーが攻めて守って，ゴールキーパーは仕事をしなくても済むという状態が理想です。ゴールキーパーが常に忙しいような試合を見たら，たとえ無得点に押さえていても，誰もが危ないと感じるはずです。得点されないように守るのはゴールキーパーだけの仕事ではないんですね。

　「守り」をテストにたとえても同じことが言えます。開発の初期段階からテストを開始し，開発者自身が単体テストや結合テスト（後述）をきっちり行い，テスト担当が行うシステム・テストでは，もはや細かいバグは出ない状態を作ることを目標にするべきです。

　かといって，優秀なチームができたらゴールキーパーはいなくてもよい，もしくは誰でもよいとはならないですよね。試合の中では攻撃陣でうまく守れたとしても，フリーキックやPKがあります。ゴールキーパーも優秀でなければならないはずですし，そうなるように自分の技術を磨こうと日々練習に励むはずです。

　ソフトウエア開発も同様です。テスト担当者はいなくてもよい，もしくは誰でもよいということはありません。テストの技術を身に付けてスキルアップしていくことが必要なのです。