テストの進捗を妨げる最大の原因は何でしょう。操作ミスをしてしまい、テストケースどおり実施できないことでしょうか。テストツールが使いこなせないことでしょうか。それとも担当者が失踪することでしょうか。

多くの組織でテストケースが消化できない最大の原因は、テスト対象のソフトウェアにバグが多すぎることです。テストをする度にバグが発生していては、いつまで経ってもテストが終わりません。試しに、バグの発生しない（OKの）テストケースと、バグの発生する（NGの）テストケースの両方について、テストケースあたりの実施時間を測定してみて下さい。圧倒的にNGの場合の方が時間がかかるでしょう。

NGテストケースの方が実施時間が長いのは、現場にいらっしゃる方なら肌でお分かりのことと思います。少なくとも不具合報告書（バグ票）を書く時間はかかりますね。OSごと落ちてしまうバグの場合は、再起動の時間がかかります。ファイルやDBの中身を壊してしまうバグが発生すると、テスト環境を全て初期状態に戻さなくてはなりません。気の利いたテスト技術者であれば、バグの切り分けを行うために、似てるけど異なる機能やパラメータ、操作手順で再テストするでしょう。もしかしたらテスト仕様が曖昧で、開発者に電話をかけなくてはいけないかもしれません。再現性を確認するために再テストも必要です。もし再現性が低かったら．．．。

したがってテストの進捗をスムーズに行うには、バグが少ないテスト対象をテストするようにすればよいのです。え？そんなこと分かってる、そんなことができれば苦労しない、そもそもそれならテストなんて要らないじゃないか、ですって？もちろん、バグの数をゼロにすることはできません。しかし「なるべく」少なくする工夫はできますよね。

その工夫の一つが「スモークテスト」です。ハードウェアの「焼き入れ試験（違うかな？）」が語源のようですね。作ったばかりのハードウェアに電源を通してみて、煙がモクモク上がってこないかどうか確認する、というテストになります。ソフトウェアの場合は、テスト対象のビルドに対してテストを開始する前に、簡単なテストを行うというものです。テスト開始資格審査と呼んでもいいでしょうし、「テスト側受け入れテスト」と呼ぶこともできます。

内容はとても簡単です。最も重要な機能や、過去に致命的なバグを起こした機能を中心に、短時間でできるテストを抜き出しておき、ビルドがテストチームにリリースされたら、ササッと実行するのです。テストプロセスに依存しますが、短ければ30分～2時間、長くても半日～1日程度で終わるようなテスト項目に絞っておきます。また凝ったバグ票は書く必要がありません。チェックリストがあれば十分でしょう。

なぜスモークテストは有効なのでしょうか。開発プロセスがきちんと機能しており、整然と管理されているプロジェクトであれば、それほど効果はないでしょう。スモークテストが有効なのは、混乱しているプロジェクトです。混乱しているプロジェクトでは、構成管理のミスによって先祖返りが起きたり、十分な数のバグが潰される前にビルドがどんどんリリースされたりします。こうしたプロジェクトでは、ビルドリリースの度に、テストチームが以前指摘したはずの不具合を検出したり、重要な機能に致命的なバグがあって他の機能のテストができなくなったりします。そこで、必要最低限の品質が確保されているかどうかをスモークテストでチェックすることにより、本来不必要なテストの遅延を防ぐのです。

またスモークテストを始めることで、ビルドリリースのタイミングを整えるきっかけができます。混乱しているプロジェクトではテストチームの都合を考えずにビルドリリースが行われるため、テストしたばかりの機能に手が入れられて再度ビルドがリリースされてしまったりします。1日に3回もビルドリリースされるプロジェクトもあります。こうなると、テスト結果が無効になってしまい、同じテストケースをビルドリリースの度に実施しなくてはならなくなってしまうのです。とてもムダですね。スモークテストをテスト側が行い、その時期をテストチームが指定すれば、開発チームにビルドリリースを我慢してもらうことができますので、落ちついてビルドごとに品質を安定してもらうきっかけになります。

スモークテストはビルドリリースの度に行うので、テストツールによる実施の自動化が効果的です。組織によっては、ビルドの直後に自動でスモークテストを実施し、スモークテストでNGが出たらビルド失敗とみなすところもあります。こうしておけば、テストチームが時間を割く必要はありません。

自動化しなくても、スモークテストのテストケースを開発チームに提示しておき、ビルドリリースの際に開発チームに実施してきてもらっても構いません。テストチームは、ビルドごとに開発チームの実施したスモークテストの結果のチェックリストを確認するだけです。これも大げさなドキュメントは要りません。

やや高等な技としては、開発チームに提示したスモークテストを、ビルドごとに少しずつ高度にしたり、数を増やすというテクニックがあります。スモークテストは開発チームにとって「当たり前に動くはずの」ハードルばかりです。ハードルを少しずつ上げていくことで、開発チームの品質意識を向上してもらうのです。致命的な不具合が発生したテストケースを中心に増やしていくとよいでしょう。また自動化を行っている場合であれば、数を増やすのも難しくありません。

スモークテストは、通過して当然のテストです。スモークテストに何度も失敗するようなプロジェクトは、非常にまずいプロジェクトだと認識するようにして下さい。そもそも仕様変更が多かったり、設計に必要な考慮事項が不足していたり、プロジェクトマネジメントがメタメタだったりします。プロジェクトが終わったら、またはプロジェクト進行中に、スモークテストの様子を確認してプロジェクト全体を見直し改善するようにしましょう。スモークテストのせいで開発チームとテストチームが対立するようなことは、絶対にないようにして下さいね。