回答。

質問の歴史:

スモークテスト（"煙のテスト"）は、システムのビルド後にその機能を迅速に確認する方法として登場しました。その目的は、重要な機能が動作していることを確認し、アプリケーションが将来のより深い検証に適しているかどうかを判断することです。手動テストにおいて、スモークテストは通常、新しい製品バージョンのデプロイ後に実施されます。

課題:

主な課題は、限られた時間の中で本当に重要な検証を選択する必要があることです。テスターはしばしば、あまりにも多くを確認して（リソースを無駄に消費して）、もしくは重要なことを見逃してしまい、リリースに「穴」が残ることがあります。

解決策:

適切なスモークテストの組織は、最も重要なユーザーフローをカバーする厳密な最小限のシナリオを選択することにあります。これらの検証は明確で、迅速かつ再現可能であるべきです。例えば：

- ユーザーのシステムへの成功したログイン
- 基本的な機能の実行が可能であること（例：購入の実施）
- 支払いの実施と確認の受け取り

主な特徴:

スモークテストは、重要な機能のみをカバーします。
頻繁なリリース時には迅速な実行が重要です。
すべてのシナリオは、事前に承認されたチェックリストに従って手動で実行されます。

注意すべき質問。

スモークテストは、回帰テストの完全な代替と見なすことができますか？

いいえ、スモークテストは、重要な機能について「動作するかどうか」の確認に焦点を当てています。重大であるが明示されていないバグを見つけるには、常に完全な回帰が必要です。

1つでもスモークテストが失敗した場合、テストを続けるべきですか？

いいえ、さらなるテストは意味がありません — チームは問題を報告し、バグが修正されるまでリリースはブロックされます。

スモークテストは、エッジケースシナリオの検証を含むべきですか？

いいえ、スモークテストはエッジケースの検証を目的としていません。これは、製品の主要機能が動作する可能性を確認するためのものです。

一般的な間違いとアンチパターン

重要でない過剰なテストの実施
スモークテストに関するドキュメントの欠如（テスターが「全てを頭の中で保持している」）
「報告性」のために明白な問題を無視すること

実生活の例

ネガティブケース

広範なチェックリストに基づいたスモークテストを実施し、重要でない機能を含んでいました。それに多くの時間がかかったため、リリースが半日遅れました。

利点:

いくつかの明白でないバグを発見しました。

欠点:

リリースの遅れ
重要でない検証にリソースと時間を費やしました。

ポジティブケース

スモークテストは最も重要なシナリオにのみ焦点を当てました。ブロッキングバグを迅速に発見し、チームに報告しました — リリースは修正まで一時停止されました。