見出し画像

スモークテストのテストケースを書く際の注意点

はじめに

以前にリグレッションテストについて記事を書きましたが、今回はリグレッションテストと似て非なるものであるスモークテストについて書きたいと思います。

ソフトウェアテストにおけるスモークテストとは、開発途中のソフトウェアをテスト(試験)する手法の一つで、起動するかどうかや基本的な機能が動作するかなどをざっと確認することです。もとは電子機器・電気機械の開発工程において電源を入れて発熱しないかを確認するテストに由来すると言われています。なので極論を言えば、エアコンであれば、煙が出なければ部屋の温度が一切変わらなくてもテストはパスしたことになるというレベルのテストというこです。

なぜスモークテストをやるのか

第一にテスト開始できる状態かどうかを判定する時にスモークテストを実行することが考えられます。基本的な部分が動かないソフトウェアの細部をテストしても、後で基本的な部分が動かないことに気がついてそのテストが無駄になる可能性があるからです。

第二に、短時間でテストを完了させることで早いサイクルでフィードバックを得られるからです。もちろん自動テストが望ましいですが、手動テストでも、新しいビルドができるたびにスモークテストを実行しておけば、最低限の品質は担保できます。基本的な部分が動かない等の問題を、なるべく早く検知して早く対応することができます。

スモークテストケース作成の注意点

スモークテストの目的が上記のとおりであるので、基本的なところをざっと確認できればよいです。状況にもよりますが、1~2時間程度で終わることが想定されます。

なるべく早く終わらせるための工夫としては、複数のシナリオを1つのユースケースに含めるということです。そしてなるべく重複しているシナリオを含めないということです。例えば、あるECサイトで仮に会員登録が3シナリオ、検索が2シナリオ、商品購入が4シナリオの場合、3×2×4=24ケースではなく、4ケースにまとめるということです。
具体的に言えば会員登録がA,B,Cの3シナリオ、検索がX,Yの2シナリオ、商品購入が1,2,3,4の4シナリオだったとしたら、ケース1は会員登録のときはシナリオAで、検索のときはシナリオXで、購入のときはシナリオ1でというようにします。同様にケース2はBY2、ケース3はCX3、ケース4はAY4のパターンでケースを作るということです。シナリオ数が少ないところは重複が出ることにはなると思います。

また、スモークテストは定期的にメンテナンスされる必要があります。もし新機能が追加されてその新機能が重要であればスモークテストに追加する必要があります。そしてできれば1つシナリオを追加するたびに1つシナリオを削除して全体のケース数を増やさないのが望ましいです。

また、短時間に終わらせるためには細かいVerificationはしないほうが良いかもしれません。すなわち検索であれば検索ボタンを押して検索結果画面が表示されれば、検索結果が正しいかどうか(1000円以上で絞り込めているか等)は確認しないで良いと思います。大切なことはリグレッションテストと混同しないことです。目的が違いますので、リグレッションテストの場合は検索結果が正しいことは確認するようにしてください。新しく入ったメンバーや経験の浅いメンバーがスモークテストの考え方をリグレッションテストに持ち込まないようにしてください。

いただいたサポートは生活費にあてます