TestLinkを運用して気付いたことpart12～スモークテストはお試しテスト

SEA関西プロセス分科会で講演後、宿口さんとNakaさんから、ブロッキングバグが多発するならスモークテストをあらかじめやってレビューで潰しておけばいいのでは、という指摘を受けて、なるほどと思ったのでメモ。

【元ネタ】
【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」: プログラマの思索

TestLinkを運用して気付いたことpart11～お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト: プログラマの思索

Software Testing - Columns: スモークテスト

スモーク テストのガイドライン

＠IT：The Rational Edge　オープンソース時代のテスト手法（2）

スモークテストの定義は下記の通り。

(引用開始)
最初に実施するテストは「スモークテスト」だ。
これは元来「ハードウェアコンポーネント」テストと呼ばれていたもので、エンジニアが慎重に部品に電源を投入し、これから実施する大規模テストに向けて十分それが安定していることを確認するものだ。
もし、部品から煙が出たり発火したりするようなことがあれば、この最初のテストは失敗ということになる。
一方、ソフトウェアのスモークテストは、基本テストをいくつか実行し、そのソフトウェアが大規模テストに耐えられるかどうか確認する。

つまり、スモークテストとはお試しテストと同義だ。
スモークテスト(お試しテスト)が必要な理由は、本来のテストの観点でテストするために、ブロッキングバグが出る回数を減らして、テスト効率を高めるためにある。

テストを実施してバグが多発した場合、失敗したテストケースに依存するテストケースはブロックになる。
ブロッキングバグがたくさん見つかるほど、ブロッキングバグ数が少なくても、ほとんどのテストケースがブロックになってしまい、テスト不能の状態に陥りやすい。
すると、本来、テストで確認したかったテストの観点の検証ができなくなり、テストの意味がなくなってしまう。

例えば、複雑な業務シナリオに基づいて、本番の業務を想定した受入テストを行っている時に、単体テストレベルの不具合がたくさん見つかり、本来のテストを進められない状況が相当するだろう。

Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は、開発プロセスがしっかりしていて、単純なバグが出ないぐらいの品質を確保されているなら、実施する必要はない。

スモークテスト(お試しテスト)が有効な場面は、プロジェクトが混乱していて、たくさんの仕様変更に対応したためにデグレードが頻発していたり、ブロッキングバグを全て潰しきれていないのに機能追加を進めている状況だ。
そんな状況では、いくら大量のテストケースを準備しても、すぐにブロッキングバグが多発して、テスト不能になってしまい、テストしても無意味な状況になる。
だから、基本的なテストケースを少数用意しておき、それをスモークテスト(お試しテスト)として実施して、ビルドモジュールの品質をあらかじめ味見しておくわけだ。

スモークテストでバグが多発するようでは本番を想定した受入テストを実施しても無意味なので、まずはスモークテストが通るレベルの品質は保証してもらえるようにあらかじめチェックしておく。
つまり、スモークテストのテストケースを品質保証部門があらかじめ作っておき、それを開発チームに渡して、開発チームはスモークテストをクリアしておくように運用する。
そうすれば、品質保証部門に渡されるビルドモジュールは最低限の品質は保証されているので、受入テストなどの複雑なテストケースを実施して、テスト効率を高めることができる。

Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は回帰テストで自動化できるようにしておくと、より効率がよくなる。
スモークテストのテストケースはあらかじめ決まっているのだから、Seleniumなどのツールを使って自動化しておけばいいだろう。

スモークテスト(お試しテスト)は全て成功するのが当たり前のテストであり、そこでNGになるようでは先が思いやられる。
特に大規模プロジェクトでは、複数チーム間でライブラリのやり取りが多くなるので、スモークテスト(お試しテスト)で品質を味見しておくようにすれば、スムーズに作業できるようになるだろう。

テストはまだまだ奥が深い技術だ。