TestLinkを運用して気付いたことpart12~スモークテストはお試しテスト
SEA関西プロセス分科会で講演後、宿口さんとNakaさんから、ブロッキングバグが多発するならスモークテストをあらかじめやってレビューで潰しておけばいいのでは、という指摘を受けて、なるほどと思ったのでメモ。
【元ネタ】
【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス~日本の品質管理技術を見直そう」: プログラマの思索
TestLinkを運用して気付いたことpart11~お試しテスト、フールプルーフテスト、探索的テスト、モンキーテスト、フェイルセーフテスト、ラッシュテスト: プログラマの思索
Software Testing - Columns: スモークテスト
@IT:The Rational Edge オープンソース時代のテスト手法(2)
スモークテストの定義は下記の通り。
(引用開始)
最初に実施するテストは「スモークテスト」だ。
これは元来「ハードウェアコンポーネント」テストと呼ばれていたもので、エンジニアが慎重に部品に電源を投入し、これから実施する大規模テストに向けて十分それが安定していることを確認するものだ。
もし、部品から煙が出たり発火したりするようなことがあれば、この最初のテストは失敗ということになる。
一方、ソフトウェアのスモークテストは、基本テストをいくつか実行し、そのソフトウェアが大規模テストに耐えられるかどうか確認する。
つまり、スモークテストとはお試しテストと同義だ。
スモークテスト(お試しテスト)が必要な理由は、本来のテストの観点でテストするために、ブロッキングバグが出る回数を減らして、テスト効率を高めるためにある。
テストを実施してバグが多発した場合、失敗したテストケースに依存するテストケースはブロックになる。
ブロッキングバグがたくさん見つかるほど、ブロッキングバグ数が少なくても、ほとんどのテストケースがブロックになってしまい、テスト不能の状態に陥りやすい。
すると、本来、テストで確認したかったテストの観点の検証ができなくなり、テストの意味がなくなってしまう。
例えば、複雑な業務シナリオに基づいて、本番の業務を想定した受入テストを行っている時に、単体テストレベルの不具合がたくさん見つかり、本来のテストを進められない状況が相当するだろう。
Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は、開発プロセスがしっかりしていて、単純なバグが出ないぐらいの品質を確保されているなら、実施する必要はない。
スモークテスト(お試しテスト)が有効な場面は、プロジェクトが混乱していて、たくさんの仕様変更に対応したためにデグレードが頻発していたり、ブロッキングバグを全て潰しきれていないのに機能追加を進めている状況だ。
そんな状況では、いくら大量のテストケースを準備しても、すぐにブロッキングバグが多発して、テスト不能になってしまい、テストしても無意味な状況になる。
だから、基本的なテストケースを少数用意しておき、それをスモークテスト(お試しテスト)として実施して、ビルドモジュールの品質をあらかじめ味見しておくわけだ。
スモークテストでバグが多発するようでは本番を想定した受入テストを実施しても無意味なので、まずはスモークテストが通るレベルの品質は保証してもらえるようにあらかじめチェックしておく。
つまり、スモークテストのテストケースを品質保証部門があらかじめ作っておき、それを開発チームに渡して、開発チームはスモークテストをクリアしておくように運用する。
そうすれば、品質保証部門に渡されるビルドモジュールは最低限の品質は保証されているので、受入テストなどの複雑なテストケースを実施して、テスト効率を高めることができる。
Software Testing - Columns: スモークテストで西さんが書かれているように、スモークテスト(お試しテスト)は回帰テストで自動化できるようにしておくと、より効率がよくなる。
スモークテストのテストケースはあらかじめ決まっているのだから、Seleniumなどのツールを使って自動化しておけばいいだろう。
スモークテスト(お試しテスト)は全て成功するのが当たり前のテストであり、そこでNGになるようでは先が思いやられる。
特に大規模プロジェクトでは、複数チーム間でライブラリのやり取りが多くなるので、スモークテスト(お試しテスト)で品質を味見しておくようにすれば、スムーズに作業できるようになるだろう。
テストはまだまだ奥が深い技術だ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
コメント