先に要点
スモークテストって名前は聞くけど、結局ふつうのテストと何が違うの いつ、どこまでやればいいの ── テスト工程の話で必ず出てくる割に、ぼんやり理解のまま使われがちな言葉です。
スモークテスト(smoke test)は、ひとことで言うと 「ビルドやデプロイ直後に、主要機能がとりあえず動くかだけを浅く広く確認するテスト」 です。
語源は電子機器の検証で、新しい基板に電源を入れて 煙(smoke)が出なければ次の検査に進む という現場の慣習から来ています。まず火を噴かないか を見る、という感覚がそのままソフトウェアに持ち込まれた言葉です。
この記事では、スモークテストの目的、何を確認するのか、いつ実行するのか、回帰テストやサニティテストとの違い、そして CI/CD での自動化のやり方と失敗パターンまでを、実務目線で整理します。
スモークテストとは何か
スモークテストは 「広く浅く」 が特徴です。一つひとつの機能を細かく検証するのではなく、システムの主要な動線が一通り通るか だけを短時間で確認します。
浅く広く
各機能を1パターンだけ、正常系中心に通す。境界値や異常系は見ない。`アプリが起動して主要画面が開く` レベルを確認する。
短時間で終わる
数十秒〜数分が目安。長くなるとデプロイのたびに回せず、`止血の速さ` という価値が薄れる。
合否が明確
主要動線が1つでも落ちたら即 NG。`細かい不具合はあるが進めてよい` のような曖昧判定をしない。
先に回す
重い回帰テストや結合テストの前に置く。ここで落ちたら、後続のテストを回すだけ時間の無駄になる。
つまりスモークテストは 「このビルドは、これ以上テストや確認を進める価値があるか」を最初に判定するゲート です。ここを通って初めて、より詳細なテストに進みます。
何を確認するのか
主要機能 の線引きは、サービスによって変わります。基準は 「これが壊れていたら、他が動いても意味がない」動線かどうか です。Webサービスなら、たとえば次のような項目になります。
| 確認項目 | 見るポイント | 落ちたら意味すること |
|---|---|---|
| アプリが起動する | トップページが 200 を返す | デプロイ自体が失敗、設定ミス |
| ログインできる | 認証フローが通る | 認証基盤・セッション・DB接続の異常 |
| 主要画面が開く | ダッシュボードや一覧が表示される | 主要機能の表示系が壊れている |
| 主要 API が応答する | 代表的なエンドポイントが正常レスポンス | バックエンドや外部連携の障害 |
| DB に読み書きできる | 読み取り中心の軽い確認 | 接続情報・マイグレーション・権限の問題 |
ポイントは 項目を増やしすぎないこと です。念のため全部確認しておこう と欲張ると、スモークテストが重くなって毎回回せなくなり、本来の 速い止血 という役割を失います。数を絞って、確実に速く が鉄則です。
いつ実行するのか
スモークテストの価値は タイミング でほぼ決まります。定番は次の3か所です。
特に 本番リリース直後のスモークテスト は省略されがちですが、ここが事故の最後の砦です。ブルーグリーンデプロイ のような安全なリリース戦略と組み合わせ、スモークが通って初めて新環境へ全トラフィックを流す 設計にすると、切り戻しが一気に楽になります。
リリースと公開の関係を整理したい場合は、デプロイとリリースの違い もあわせて読むと、どの段階でスモークを置くかが見えやすくなります。
回帰テスト・サニティテストとの違い
スモークテストは、回帰テストやサニティテストと混同されがちです。役割を分けて整理します。
| 種類 | 目的 | 範囲 | かける時間 |
|---|---|---|---|
| スモークテスト | 主要機能がとりあえず動くかの判定 | 広く浅く(主要動線のみ) | 数分以内 |
| サニティテスト | 特定の修正・機能が正しく動くかの確認 | 狭く浅く(変更箇所周辺) | 短い |
| 回帰テスト | 既存機能が壊れていないかの網羅確認 | 広く深く(全体) | 長い(数十分〜数時間) |
ざっくり言うと、スモークは「全体が生きているか」、サニティは「この変更は妥当か」、回帰は「どこも壊れていないか」 です。
スモークとサニティはどちらも 浅い テストですが、スモークが システム全体を広く 見るのに対し、サニティは 特定の変更点を狭く 見る、という向きの違いがあります。
実務では スモークテストを最初のゲートにして、通ったら回帰テストへ という順番で組むのが一般的です。Playwright のような E2E テストツールで主要動線だけを抜き出したテストを smoke タグで分け、回帰用の重いテストと使い分けると運用しやすくなります。
CI/CDでの自動スモークテスト
スモークテストは CI/CD に組み込んで自動化してこそ効きます。手動だと 急ぎのリリースのときに限って省略される からです。
もっとも軽い形は、デプロイ 後に主要エンドポイントへ HTTP リクエストを投げ、ステータスコードを確認するスクリプトです。たとえば次のように、主要パスが 200 以外を返したら即失敗させます。
| 確認の段階 | やること | NG時の挙動 |
|---|---|---|
| 主要URLの疎通 | トップ・ログイン・代表APIへ curl して 200 を確認 | パイプラインを失敗させ後続を止める |
| ヘルスチェック | /api/health がDB接続まで見て正常を返すか確認 | 自動ロールバックを発火させる |
ポイントは 専用のヘルスチェック用エンドポイント(例: /api/health)を用意し、その中で DB 接続や外部依存まで軽く確認させる ことです。トップページの 200 だけだと、画面は出るが DB が死んでいる 状態を見逃します。ヘルスチェックの中で軽い読み取りクエリを1本流しておくと、接続断やマイグレーション漏れをこの段階で拾えます。
デプロイ手順にこのスクリプトを挟み、スモークが NG なら自動でロールバックする ところまで組むと、リリース事故の被害をかなり抑えられます。本番デプロイ時のDBマイグレーション の確認とも相性がよい部分です。
よくある失敗と注意点
スモークを厚くしすぎる
あれもこれもと項目を足して実行に10分かかるようになると、毎回回せず形骸化する。原因は「念のため」での追加。回避は、深い検証は回帰テストへ移し、スモークは主要動線だけに絞ること。
本番で書き込みテストをして事故る
本番スモークで会員登録や決済を実行し、テストデータが本番に残る。回避は、本番では読み取り中心にする、専用のテストアカウントとフラグで隔離すること。
不安定テストで狼少年化する
外部APIのタイムアウト等でたまに落ちると、`また誤検知か` と無視されるようになる。回避は、リトライや待機を入れ、本当に主要な動線だけを対象にすること。
スモークテストは 「速く・確実に・止められる」 が揃って初めて意味を持ちます。遅い たまに落ちる 落ちても止めない のどれかがあると、あっという間に形だけのテストになります。
スモークテストに関するよくある質問
Q. スモークテストは手動と自動のどちらでやるべきですか？
A. 自動を強くおすすめします。スモークテストの価値は 毎回必ず実行されること にあり、手動だと急ぎのリリースで省略されがちです。CI/CD に組み込み、デプロイのたびに自動で走る状態にしておくのが基本です。最初は数本の主要URLの200確認だけでも十分効果があります。
Q. スモークテストと E2E テストは何が違いますか？
A. E2E テストは「テストの実行方式(画面操作を端から端まで通す)」を指し、スモークテストは「テストの目的(主要機能がとりあえず動くか)」を指す言葉です。重なる部分はあり、実務では E2E ツールで主要動線だけを抜き出したものをスモークテストとして使うことがよくあります。
Q. どのくらいの項目数が適切ですか？
A. 明確な正解はありませんが、実行が数分以内に収まる範囲 が一つの目安です。項目としては、起動・ログイン・主要画面・主要API・DB疎通など、5〜10個程度に絞るケースが多いです。増やしたくなったら、それは回帰テスト側に置くべき項目でないかを疑います。
Q. 本番環境でスモークテストをしても大丈夫ですか？
A. 読み取り中心にすれば問題ありません。むしろ本番リリース直後のスモークは事故の最後の砦です。ただし会員登録・決済・メール送信のような副作用のある操作は避け、専用のヘルスチェックエンドポイントや読み取り専用の確認に寄せます。
Q. スモークテストが落ちたらどうすればいいですか？
A. まず後続の工程を止め、リリース直後なら速やかにロールバック(切り戻し)します。原因調査はその後です。落ちたまま先に進める のが最悪のパターンで、スモークテストを置いた意味がなくなります。CI で失敗時に自動で止まる・戻る設定にしておくと確実です。
Q. 小さな個人開発でもスモークテストは必要ですか？
A. 規模が小さいほど、軽いスモークテストの費用対効果は高いです。デプロイ後にトップとログインが200か を確認する数行のスクリプトを入れるだけでも、デプロイしたら真っ白だった という事故をかなり防げます。最初から大掛かりにする必要はありません。
Q. スモークテストとヘルスチェックは同じものですか？
A. 近いですが別物です。ヘルスチェックは 稼働中のシステムが生きているか を継続的に監視する仕組み、スモークテストは 新しいビルド/デプロイが最低限動くか をリリース時に確認する工程です。ただしスモークテストの中でヘルスチェック用エンドポイントを叩くことは多く、両者は連携して使われます。
参考リンク
- Google Testing Blog: Test Sizes
- Martin Fowler: Testing Strategies in a Microservice Architecture
- ISTQB: Glossary(Smoke test / Sanity test)