TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス

僕はテスト技法を体系的に知らないが、TestLinkを過去1年間実践してみて、テスト戦略やテストケースの作成方法について、ノウハウは色々溜めてきた。

TEF関西のNakaさんからテスト技法の専門用語を教えてもらい、そのノウハウに専門用語が付けられているのを知ったので、まとめてみる。

【元ネタ】
JSTQBテスト技術者資格認定-シラバス（学習事項）・用語集-

ソフトウェアテスト標準用語集 日本語版Ver 1.3

【1】みなしバグとブロッキングバグ

TestLinkのテストケースには「ブロック」という状態がある。

ソフトウェアテスト標準用語集 日本語版Ver 1.3 によれば、ブロックとは「事前条件を満足できないため、実行不能のテストケ－ス」を指す。
つまり、失敗したテストケースに依存するテストケースがブロックの対象になる。
例えば、小売系Webシステムならば、カート画面のDB更新のテストケースで失敗したら、注文フローは全てブロックになるだろう。

Nakaさんによれば、失敗したテストケースのバグを「ブロッキングバグ」、ブロックしたテストケースを「みなしバグ」と言うらしい。

つまり、ブロックしたテストケースは、「ブロッキングバグ」が直らなければ、再テストできない状態にある。
ブロックしたテストケースは「みなしバグ」だから、一生懸命テストしたとしても工数の無駄だ。
実際のテストでは、バグが出るたびに「みなしバグ」のテストケースを判別するのが非常に難しく、テスト工数を無駄に浪費してしまいがちだ。

管理者は、バグが出るたびに依存するテストケースをブロックして、他のテストを指示したり、再テストのタイミングを図る。
TestLinkでは、テスト実績やバグチケットの状態をリアルタイムに表示できるため、再テストの指示がやりやすくなる。

「ブロッキングバグ」は滞留時間が長くなるほど、ブロックしたテストケースのテスト工数も加算すれば、再テスト工数が大きく増える。
テスト工程は普通、プロジェクト後半という時間が限られた状況にあるため、管理者は、再テストのタイミングを図りながら、バグ修正の優先順位付けをする意思決定が重要になってくる。

テストケースをブロックする判定条件は、どんなものがあるだろうか？

TestLinkにはテストスイートという階層構造があり、テストスイートに、システムの機能(大・中・小)・テストの目的・業務シナリオなどの項目を当てはめる。
例えば、結合テストのように業務シナリオや画面遷移のパターンでテストする場合、一つのシナリオに複数のテストケースが属している。
従って、シナリオに含まれる一つのテストケースが失敗した場合、それ以降のシナリオのテストケースは全てブロックになる。

TestLinkでは、テスト実行画面でテストスイートの単位でテストケース数が集計表示されるので、どれくらいのテストケースがブロックになるか、判断しやすい。

しかし、TestLinkのブロックしたテストケース一覧画面には、ブロッキングバグの発生源である失敗したテストケースとリンクする機能が無いのが惜しい。

【2】周辺テスト

「周辺テスト」とは、再テスト時に、ある観点にグループ化されたテストケース群を回帰テストすることを呼ぶらしい。

例えば、小売系Webシステムで、カート画面で商品削除のテストケースで失敗したとしよう。
バグが直っていない場合、カート投入したテストケースは「成功」、カートから商品削除のテストケースは「失敗」、注文フローは全て「ブロック」になっているだろう。

そして、バグ修正して、バグ検証が終わり、ブロッキングバグが解消されたとする。
すると、カートから商品削除のテストケースは再テストして「成功」にできるが、カート投入したテストケースももう一度回帰テストすることを「周辺テスト」と呼ぶ。

「周辺テスト」をやる理由は、ブロッキングバグの修正でデグレしていないかのチェックをしたいからだ。
実際の運用では、シナリオに従って画面からデータを作り直して再テストするから、失敗したテストケースの前に既に成功を確認したテストケースを自然に回帰テストしているだろう。

TestLinkでは、テスト結果の履歴を保持できるため、回帰テストを管理しやすい利点がある。

【3】みなしOK

VerUpしたシステムのテストをする場合、ソース修正されていない機能のテストケースは「みなしOK」として、テストしない判断をする。
おそらく管理者や設計者がその判断を下しているだろう。

本来ならば、ソース修正されていない機能のテストケースも回帰テストでテストすべきだ。
なぜなら、機能追加によって、他の部位にも影響が出てバグが発生しているかもしれないからだ。

しかし、実際はテスト工数を確保できないため、この要件は単体テスト済みなのでテスト不要、とか、このテストはシステムテストでやるから今のテスト計画ではテストしない、などのテスト戦略を採用しているだろう。

あるいは、既に本番稼動して特に問題ないので、この機能は運用品質を満たしているという判断を下す場合もあるだろう。

「みなしOK」の判断はとても難しく、設計者の技量を問われる部分でもある。

【4】テストケースにもクリティカルパスがある

テストに失敗してバグが増えると、ブロックしたテストケースは飛躍的に増える。
すると、テストケースの失敗率のある上限値を超えると、テスト計画に含まれる全てのテストケースがブロックになってしまい、テスト不能になる状況が考えられる。
つまり、テスト不能の状況は、全てのブロッキングバグを最優先に修正しなければ、テストしても無駄な状態を意味している。

TestLinkのテスト計画をXPのイテレーション、Scrumのスプリントのように扱って順次テストしていく戦略を採る場合、テスト工数にバグ修正とバグ検証の工数も考慮する必要がある。
つまり、テストケースにはクリティカルパスの概念がはっきりと存在する。

例えば、テスト計画が小売系Webシステムの結合テストのPh1だったと仮定しよう。
TestLinkのテスト計画をXPのイテレーションに見立てると、２～４週間で全てのテストが終わる前提でテスト戦略を作る必要がある。

ここで、それぞれのテストケースにテスト予定工数を記入しておいたとしよう。
TestLinkでは、テストケースにテスト予定工数のカスタムフィールドを用意すればいいだろう。
すると、テスト予定工数の総和がテスト計画の最低限の予定工数となる。

更に、テストスイート単位の予定工数も計算できるので、ブロッキングバグが発生した場合、再テストの予定工数も計算できる。
この場合の予定工数は、失敗したテストケースの工数、ブロックしたテストケースの工数の和、バグ修正の工数の3つの和になる。
従って、ブロッキングバグのチケット単位で再テスト工数を一覧表示できる。

テストケースは普通シナリオベースのため、先行・後行関係があるから、テストケースのPERT図に再テスト工数を入れれば、そこからクリティカルパスを見出すことができる。

つまり、テスト計画から想定されるバグ数から、再テスト工数も予想で計算できるので、それを足せば、テスト計画の予定工数になる。

バグが頻発した場合、管理者はテストケースの依存関係と再テスト工数の一覧を見ながら、どのバグを最優先で直して再テストすべきか、という意思決定ができる。
あるいは、テストチームは開発チームへ、このバグは再テスト工数と納期を考慮すると、MM月DD日までに修正してもらわないと納期に間に合いません、と連絡することもできる。

これがテスト工程における本来のマネジメントなのだろう。

現状のTestLinkでは、工数計算やスケジュール管理の機能は無く、クリティカルパスを見つけるのは難しい。
TestLinkCnvMacroでテストケースとテスト実績をExcelで出力して、Excel上で解析するしかない。

【まとめ】
オブジェクト指向プログラミングでは、デザインパターンと言うベストプラクティス集がある。
デザインパターンがあるからこそ、他の開発者と概念を共有できるし、プログラムも綺麗になる。

同様に、TestLinkはオープンソースのため、世界中の技術者の要望が組み込まれたテストに関するベストプラクティス集の集まりみたいなもの。
「ブロック」や「ビルド」のように、TestLinkの機能には、先人の知恵が詰まっている。

最近思うのは、RedmineにせよTestLinkにせよ、オープンソースの管理ツールには、ベストプラクティスがたくさん詰まっていること。
Redmineにある「ワークフロー」の柔軟な機能を上手に使えば、ITILの変更管理に似た運用ができる。
更に、Redmineを使いこなせれば、チケット駆動開発を実践できて、自然にアジャイル開発になる。

同様にTestLinkも使いこなせれば、テスト技法の理論を試しながら、テスト技法の経験を積むことができるだろう。