サニティテストとスモークテスト：主な違い、例、それぞれの使用タイミング

スモークテストとサニティテストの比較表

側面	スモークテスト	健全性テスト
主な目標	ビルドの安定性を確認する	変更の機能性を確認する
対象領域	広範囲（アプリケーション全体）	狭い（特定のモジュール）
深さ	浅いテスト	ディープテスト（ターゲット）
によって演奏された	開発者またはテスター	テスターのみ
ビルド状態	初期/不安定なビルド	比較的安定したビルド
ドキュメント	脚本と文書	通常は台本なし
テストサブセット	受け入れ試験	回帰テスト
オートメーション	強くお勧めします	手動または自動で実行可能

ソフトウェアビルドとは何ですか?

たった1つのソースコードファイルで構成される単純なコンピュータプログラムを開発する場合、そのファイルをコンパイルしてリンクするだけで実行可能ファイルを作成できます。このプロセスは簡単です。しかし、通常はそうではありません。典型的なソフトウェアプロジェクトは、数百、あるいは数千ものソースコードファイルで構成されます。これらのソースファイルから実行可能プログラムを作成するのは、複雑で時間のかかる作業です。実行可能プログラムを作成するには、「ビルド」ソフトウェアを使用する必要があります。このプロセスは「ソフトウェアビルド」と呼ばれます。

発煙試験とは何ですか?

スモークテストは、ソフトウェアのビルド後に実行されるソフトウェアテスト手法であり、ソフトウェアの重要な機能が正常に動作しているかどうかを検証します。詳細な機能テストや回帰テストを実行する前に実行されます。スモークテストの主な目的は、欠陥のあるソフトウェアアプリケーションを拒否することです。これにより、QAチームが壊れたソフトウェアアプリケーションのテストに時間を無駄にすることがなくなります。

スモークテストでは、選択されたテストケースはシステムの最も重要な機能またはコンポーネントをカバーします。目的は網羅的なテストではなく、ソフトウェアアプリケーションの主要機能が正しく動作することを確認することです。例えば、典型的なスモークテストでは、アプリケーションが正常に起動するか、GUIが応答するかなどが検証されます。

サニティテストとは何ですか?

サニティテストとは、コードまたは機能に軽微な変更を加えたソフトウェアビルドを受け取った後に実施されるソフトウェアテストの一種で、バグが修正され、これらの変更によって新たな問題が発生していないことを確認することを目的としています。このテストの目的は、提案された機能がほぼ期待通りに動作することを確認することです。サニティテストに不合格となった場合、より詳細なテストに時間とリソースを費やすことを避けるため、ビルドは拒否されます。

目的は「徹底的な機能性を検証すること」ではなく、開発者がソフトウェアの開発において一定の合理性（健全性）をもっているかどうかを判断することです。例えば、関数電卓の計算結果が「2 + 2 = 5！」だった場合、sin 30 + cos 50のような高度な機能をテストしても意味がありません。

用語の歴史と起源

「スモークテスト」という用語は、ハードウェアおよびエレクトロニクス業界に由来します。エンジニアは新しい回路基板に初めて電源を入れる際、煙が出ないか確認します。これは根本的な欠陥の兆候です。煙が出なければ、基本的なテストを進めることができます。この概念は、1980年代にソフトウェアテスターに​​よって初期ビルド検証を表すために採用されました。

一方、「サニティテスト」とは、特定の変更の「サニティ（健全性）」または合理性を確認することを指します。この用語は、ソフトウェアが変更後に合理的かつ論理的に動作することを確認することに重点を置いており、本質的には「これは理にかなっているか？」と問うことになります。

スモークテスト vs. サニティテスト vs. 回帰テスト

これら 3 種類のテストがどのように連携するかを理解することは、効果的な QA 戦略にとって重要です。

• スモークテスト 最初に、ビルドがテストできるほど安定していることを確認します。
• 健全性テスト （該当する場合）次のようになります - 特定の変更または修正が正しく機能することを確認します。
• 回帰テスト 最も包括的であり、新しい変更によって既存の機能が損なわれないことを保証します。

これを漏斗として考えてみましょう。スモーク テストは不安定なビルドを素早く除外する広い開口部であり、健全性テストは特定の変更に焦点を絞り、回帰テストはシステム全体を徹底的にカバーします。

実際のシナリオ: 電子商取引アプリケーション

ショッピング カートのバグを修正した新しいビルドを受け取った電子商取引 Web サイトを考えてみます。

スモークテスト: QAではまず、ウェブサイトが読み込まれるか、ユーザーがログインできるか、商品が正しく表示されるか、検索が機能するか、チェックアウトプロセスが開始されるかを検証します。これには約15～30分かかります。

正気テスト: スモークテストに合格すると、テスターはショッピングカートの機能（商品の追加、数量の更新、商品の削除、計算の検証）に重点的に取り組みます。このターゲットテストには約30～60分かかります。

両方とも合格すると、チームは完全な回帰テストに進みます。これは、アプリケーションの複雑さに応じて数時間または数日かかる場合があります。

スモークテストとサニティテストの使い分け

スモークテストを使用するのは次のような場合です。

• 新しいソフトウェアビルドがテスト環境に展開されます
• ログイン、ナビゲーション、データフローなどの重要な機能を迅速に検証する必要がある
• ビルドがさらに詳細なテストを行うのに十分安定しているかどうかを判断する
• 自動ビルド検証のための CI/CD パイプラインへの統合

次の場合に健全性テストを使用します:

• マイナーコードの変更、バグ修正、機能強化が実装されます
• 特定の変更が意図したとおりに機能することを確認する
• ビルドは以前のスモークテストからすでに比較的安定している

利点と制限

優位性

• 重大な問題を迅速に特定: どちらの方法でも、テストを停止させる可能性のある問題を迅速に特定できます。
• リソース効率: チームは根本的に壊れたビルドの詳細なテストに時間を無駄にしません。
• 早期欠陥検出: サイクルの早い段階で問題を発見すると、全体的な修正コストが削減されます。
• リリースサイクルの高速化: 効率的なゲートキーピングにより、反復と展開が高速化されます。

製品制限

• 限られた範囲: どちらのテスト タイプも、アプリケーション全体を包括的にカバーするものではありません。
• 隠れたバグを見逃す可能性があります: 統合の問題やエッジケースが検出されない可能性があります。
• 完全なテストの代わりになるものではありません: これらはクイック フィルターとして機能し、回帰テストの代わりとなるものではありません。

実装のベスト プラクティス

スモークテストの場合:

• スモーク テストを自動化し、すべてのビルドの CI/CD パイプラインに統合します。
• スモーク テスト スイートは重要な機能のみに焦点を当てるようにし、大きくなりすぎないようにします。
• 重要な機能が追加または変更されるたびに、スモーク テストを更新します。

健全性テストの場合:

• 健全性テストのシナリオを作成する前に、必ず変更ドキュメントを確認してください。
• 変更された領域とそれに隣接する機能にテストの取り組みを集中させます。
• 探索的テスト手法を使用して、予期しない問題を発見します。

避けるべき一般的な間違い

• 2 つのテスト タイプを混同する: スモーク テストは広く浅く、健全性テストは狭く深く行われます。
• 時間を節約するためにスモークテストをスキップする: これにより、不安定なビルドで無駄な労力がかかることがよくあります。
• スモークテストを包括的にしすぎる: これでは迅速な検証の目的が達成されません。
• 失敗後の続行: どちらかのテスト タイプが失敗した場合は、続行する前に停止して問題に対処してください。

スモークアンドサニティテストに推奨されるツール

• Selenium ウェブドライバー: ウェブアプリケーションテスト自動化の業界標準
• TestNG/JUnit: 自動テストを整理して実行するためのテストフレームワーク
• Jenkins/GitHub アクション: ビルドとテスト実行を自動化する CI/CD ツール
• Cypress: 開発者に優しい最新のエンドツーエンドのテストフレームワーク
• Postman/安心してください： バックエンドのスモークテスト用の API テストツール

よくあるご質問