TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念

TestLinkのテストケースの概念についてのメモ書き。

【元ネタ】
TestLink 実戦投入 - かおるんダイアリー

TestLinkの「テストケース」も「テスト計画」と同様に、「ビルド」(回帰テストの実施結果)と1対多の関係になる。

「テストケース」の状態遷移図を考えると、下記のようなフローになる。

アサイン前→未実行→成功 or 失敗 or ブロック

「アサイン前」の「テストケース」は「テスト仕様」にあるが「テスト計画」にアサインされていない状態。
つまり、イテレーション計画に組み込まれていないので、TestLinkへただ貯めている状態になる。

「未実行」の「テストケース」は「テスト計画」にアサインされて、いつでもテストを開始できる状態。
テスターは担当の「テストケース」をフィルタリングして、どんどんテストをこなしていく。

テストケースがいつも「成功」ならば良いが、やはり「失敗」する時もある。
この時、「失敗」したテストケースに依存するテストケースにも「ブロック」を付けて、テスト保留とする。

つまり、「ブロック」とは、バグが直らないと先に他のテストケースをテストしたとしても、再検証が必要になるテストケースの状態を指す。
例えば、Amazonのような小売系Webシステムでカート画面のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になるだろう。

TestLinkのテスト実施時には「ブロック」を上手に使うことが重要だ。
上記のような「ブロック」するテストケースは「見なしバグ」と言われるらしい。
つまり、テストしていないから失敗してないし、バグも出ていないが、テストしたら必ずバグが出ることになる。

「見なしバグ」のテストケースは一生懸命テストしたとしても、工数の無駄だ。
実際の現場では、バグが多発すると「見なしバグ」の切り分けが難しく、プロジェクト後半と言うただでさえリソースが少ない状況で、工数を無駄に浪費してしまいがちだ。
だから、「見なしバグ」のテストケースは保留として、他のテストを先行したり、本来のバグが修正したらすぐに再テストする管理が必要になる。

TestLinkでは、テスト結果をリアルタイムにモニタリングできるため、テスト結果を見ながら管理者はバグの状況に応じて、テストを中断したり、別のテストを指示したりする。

TestLinkの機能で惜しいのは、失敗したテストケースはバグ管理IDとリンクできるが、ブロックしたテストケースの発生源である失敗したテストケースIDにリンクする機能がないことだ。
ブロックの発生源のテストケースのステータスがTestLinkのテスト結果上で分かるようになれば、管理者の指示なしでテスターが自発的にテストできる状況になる。

TestLinkによるテスト管理には、世界中のテスト技術者のノウハウがたくさん詰まっていると思う。