コンピュータ プログラミングおよびソフトウェア テストでは、スモーク テスト(コンフィデンス テスト、サニティ テスト[ 1 ] 、ビルド検証テスト( BVT ) [ 2 ] [ 3 ] [ 4 ] 、ビルド受け入れテストとも呼ばれる) は、たとえば将来のソフトウェア リリースを拒否するのに十分なほど深刻な単純な障害を明らかにするための予備テストまたはサニティ テストです。スモーク テストは、コンポーネントまたはシステムの最も重要な機能を網羅するテスト ケースのサブセットであり、ソフトウェアの主要機能が正しく動作しているように見えるかどうかの評価を支援するために使用されます。 [ 1 ] [ 2 ]コンピュータ プログラムをさらに詳細なテストにかける必要があるかどうかを判断するために使用される場合、スモーク テストは、プレテスト[ 5 ]またはインテーク テスト[ 1 ]と呼ばれることがあります。あるいは、ビルドがテスト チームにリリースされる前に、ビルドがテスト可能であることを検証するために、製品の各新しいビルドに対して実行される一連のテストです。 [ 6 ] DevOpsパラダイムでは、ビルド検証テストステップの使用は、継続的インテグレーション成熟段階の特徴の1つです。[ 7 ]
例えば、スモークテストでは、「プログラムは実行されるか?」「ユーザーインターフェイスは開くか?」「メインボタンをクリックすると何かが起こるか?」といった基本的な質問に答えることができます。スモークテストのプロセスは、アプリケーションがひどく壊れていて、それ以上の即時テストが不要になるかどうかを判断することを目的としています。書籍「ソフトウェアテストで学んだ教訓」[ 8 ]にあるように、「スモークテストは限られた時間で製品の機能を幅広くカバーします。[...]主要な機能が動作しない場合や、主要なバグがまだ修正されていない場合、チームはインストールやテストにこれ以上の時間を費やすことはありません。」[ 3 ]
スモークテストは多くの場合短時間で完了するため、より大規模なテストスイートを実行するよりも迅速なフィードバックが得られるという利点があります。大規模なテストスイートを実行すると、当然ながら時間がかかります。
スモークテストによる頻繁な再統合は、業界のベストプラクティスの1つです。[ 9 ]理想的には、ソースコードリポジトリへのすべてのコミットが継続的インテグレーションビルドをトリガーし、回帰をできるだけ早く特定する必要があります。ビルドに時間がかかりすぎる場合は、複数のコミットを1つのビルドにまとめるか、非常に大規模なシステムを1日に1回再構築することができます。全体として、可能な限り頻繁に再構築して再テストしてください。
スモークテストは、ビルドを次のテストに進める前にテスターによっても実施されます。マイクロソフトは、コードレビューの後、「スモークテストはソフトウェアの欠陥を特定して修正するための最も費用対効果の高い方法である」と主張しています。[ 10 ]
スモークテストは、手動で行うことも、自動ツールを使用することもできます。自動ツールを使用する場合、ビルドを生成するプロセスがテストを開始することがよくあります。
スモークテストは、機能テストまたは単体テストに分類できます。機能テストは、さまざまな入力を用いてプログラム全体を実行します。単体テストは、個々の関数、サブルーチン、またはオブジェクトメソッドを実行します。機能テストは、プログラム入力のスクリプト化、場合によってはマウスの動きを制御する自動化メカニズムを含むこともあります。単体テストは、コード自体の中に独立した関数として実装することも、テスト対象のコードを変更せずにコードにリンクするドライバレイヤーとして実装することもできます。
『ソフトウェアテストで学んだ教訓』の中で、セム・カナー、ジェームズ・バッハ、ブレット・ペティコードはこの用語の由来を次のように説明しています。「スモークテストという言葉は、電子ハードウェアのテストから来ています。新しいボードを接続して電源を入れます。ボードから煙が出ているのを見たら、電源を切ります。それ以上のテストは必要ありません。」[ 3 ]