Posted at

スモークテストのすゝめ

スモークテストとは何か?

IT用語辞典より


開発・修正したソフトウェアを実行可能な状態に組み立て、起動するかどうかや基本的な機能が動作するかなどをざっと確認すること。


となっているが、もう少し具体的に定義する。


  • 実装者による動作確認

  • 単体テストと結合テストの間に位置するもの

実装者をサーバーサイドに仮定すると、


  • クライアントや外部サービス向けのAPIの動作確認

  • バッチ処理の動作確認

となるが、今回は都合上クライアントの動作確認に限定する。

つまり、サーバーサイドエンジニアが実施するステージング環境でのAPIの動作確認ついて考える。

なぜ、スモークテストが必要か。

単体テストは実施済みという前提で考える。テストファーストて何?という人もまずはそちらから調べてください。

テスト駆動開発自体はだいぶ普及して、実際にカバレッジがある程度ないとレビュー通さないという文化もできてきている。それでもバグは減らない。単体テストをどう完璧にしてもステージングや本番でのバグは減らない。

その理由の一つとして結合テストや総合テストのリソース不足がある。

リリース日が遅らせられない場合は、実装フェーズが遅延するほどテストフェーズにしわ寄せがくる。

予定より少なくなった時間で品質を担保するのは無理で、どうしても項目を少なくしたりするしかない。

そこで、バグが発見されて戻しが発生するとなおさらである。

スモークテストはそういう状況を少しでも減らすのが目的である。

どういうことか?

そもそも単体テストの実施のみでステージングでQA開始になったとたん、いきなりつまづくことがある。

その原因は、例えば


  • ファイルのデプロイ漏れ

  • 設定が漏れている

  • デプロイが失敗しているのに気づかない

  • DBのテーブルが作成されていない

  • テストデータが用意されていない

などなどである。

そのため、QAから「なんかエラーで動かないんですけど」と聞かれて調べてみると上記のような凡ミスが多い。

その時間(再デプロイを含む)だけでも、数十分から長いと数時間になる。

そして、QA側のストレスも貯まり、こういった状況が続くとお互いの信頼関係にも影響がある。

また、結合テスト本来の目的であるサービス間のテストやデータの整合性のテストの時間も食いつぶしてしまう。

スモークテストはそういったQA側の負担を減らすために実装者が実施するテストである。

上記に対応してみると


  • マージするプルリクエストに対象コードが全て含まれているか

  • 各種設定ファイルは開発環境だけでなくステージング環境も追記・更新済みか

  • デプロイは正常終了しているか

  • マイグレーションは正しく反映されているか

  • テストデータなどは自動または手動で生成されているか

    などを確認した上で、さらに実際に動作確認する。

    APIの確認はポストマンが必須と思っていい。

    https://www.getpostman.com/

    ポストマンが便利なところは、


  • headerやbodyをエンドポイントごとに保存が可能


  • content-typeの設定が簡単


  • jsonの記述が簡単


などである。

そして、ステージングのエンドポイントを叩いてみる。想定した結果が返ってくればOK。ただそれだけである。

このスモークテストを実施することにより、QA側は最初からスムーズに結合テストに入れる。数分の手間で無駄な数時間をうまなくてすむ。また、スモークテスト中に実装バグに気づくこともあり、そこで修正できればさらに以降のリソースも浪費しなくてすむ。

スモークテストという名前の由来は、昔、配管工が工事を終了したときに煙を流してみてどこからも漏れていないかチェックした事からという説がある。

私たちも、ものづくりの一端を担うものとして最低限のQA(=品質保証)を担保するようにしたい。