ブロッキングバグの事例

TestLinkのテスト実行画面には「成功」「失敗」の他に「ブロック」がある。(ソフトウェアテスト標準用語集 日本語版Ver 1.3)
普通は、失敗時に、失敗したテストケースに依存するテストケースをブロックにして、テスト保留にする。

ここで、ブロッキングバグとは、失敗したテストケースの機能のバグのうち、リリースを妨げるような重大なバグを指す。
ブロッカーバグとも言われるらしい。
更に、ブロックしたテストケースの機能は、みなしバグと呼ばれる。

Tracのチケットでは、緊急性が最も高い優先度が「blocker」になっているが、ブロッキングバグはそれに当たると思う。

このブロッキングバグの事例を見つけたのでメモ。

【事例1】
ある会社の新人チームが開発後テスト中にブロッキングバグに遭遇した事例が書かれている。
緊迫した内容がリアルで、とても素晴らしい。

コラム[直し壊しのテストフェーズ]‐株式会社アーツテック[ARTSTECH]

特に、結合テストやシステムテストでは、バグ修正と同時にテストデータの準備や本番環境の構築作業を行わなければならない。
この時に、どの作業を優先して行うか、意思決定が迫られる。

普通は、ブロッキングバグを最優先に直すのが先だ。
理由は、ブロッキングバグが直らないと、未検証の機能はみなしバグの状態になってしまい、テストしても無意味だからだ。
ブロッキングバグはまさにリリース不能にさせるバグ、プロジェクトの動き全体を文字通りブロックしてしまう危険なバグなのだ。

【事例2】
Mozillaが安定していなかった頃のQAメールのやり取り。

もじら組フォーラム [One Topic All View / Re[7]: Mozilla 1.3 for Mac OS X でメールフォルダ名が文字化け / Page: 0]

(前略)
ただですらユーザの少ないMac版のしかも日本語処理のバグなんで声を出さないとなかなか注目を浴びないと思います。
Bugzilla-jpでバグを立てると国内の有志が協力してくれるとしょう。
どちらも内容的にはブロッキングバグになってしかるべきものと思います。
(後略)

もじら組フォーラム [One Topic All View / Re[1]: Mozilla 1.4 リソースリーク? / Page: 0]

(前略)
1.4は1.0.xに変わる安定系という役割なのに、何を焦っているのか、ブロッカーバグをつぶさずリリースしたことが、今回の失態につながっている。
MozillaはともかくNetscape 7.1は大問題だと思う。
これさえなければ、Netscape復活といえる出来なだけに誠に残念。
ショボイOSにも問題はあるが、早急に修正版を出して欲しい。
(後略)

ブロッキングバグを無視してリリースしてしまった為、ユーザから製品に対する信頼を落とした事例として非常に耳が痛い。
ブロッキングバグを残したままリリースした場合、ブロックした機能は未検証のため、品質に疑問符が付いたままになる。

結局、ユーザにブロックしたテストケースを再テストさせているようなものだ。
つまり、みなしバグをユーザがテストして、はっきりとバグと判明させたようなもの。
プロの技術者として恥ずかしいだろう。

テスト管理には、プログラミングとは違った特有の技術があるように思う。