TestLinkのベストプラクティス集

TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。
あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

TestLinkのFAQ: プログラマの思索

テスト手法の概念をTestLinkで説明する: プログラマの思索

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

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkを受入テストで運用する方法: プログラマの思索

Test Linkのテスト手法 from akipii Oga

TestLinkを受入テストで運用 from akipii Oga

【1】ブロック

テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。
ブロッキングバグが原因でテスト不能になった状態でもある。

例えば、Webのカート画面でカート投入のテストが失敗した場合、注文フローのテストケースは全てブロックになる。カート投入機能にバグがあるのだから、その状態で注文のテストを続けても無意味だからだ。

実際のテスト工程では、テストに失敗した場合、そのまま続行するかどうかの判断がすごく難しい。
テスト工程でテスターが大量投入される状況が多いので、システムの仕様を知らないテスターはその判断が難しいからだ。

テスト計画やテスト戦略がきちんと徹底されていないチームでは、ブロックすべきテストケースを実施して、テスト工数を無駄に浪費する。
つまり、NGが出たら、関係するテストケースはブロックで一時保留とし、他のテストケースにリソースを費やしたり、バグ修正に専念する方が賢明だ。

ブロックするかどうかの判断のために、テストケースの依存関係もテスト仕様書へ記述しておくと、テスターが作業しやすくなるだろう。
TestLinkには、テストケースの属性にキーワードがあるので、この項目に依存するテストケースを追記する運用方法もあるだろう。

【2】みなしNG

失敗したテストケースが原因で、テスト未実施だが失敗になる状態を指す。
ブロッキングバグが原因でテストしなくても失敗になる状態でもある。

例えば、Webのカート表示機能のテストで失敗した場合、カート追加やカート削除の機能も当然、テストを実施しなくても失敗が予想されるので、それらのテストケースをみなしNGとして、失敗ステータスにする。

実際のテストでは、みなしNGとブロックの使い分けは運用ルールによって異なるけれども、テストチームが開発チームへ実際の厳しい現状を伝えるために、故意に「みなしNG」を使ってびびらせる場合もある。
ブロックはあくまでもテストが一時保留だが、みなしNGはテスト失敗とカウントされるので、システムの品質が悪い事実としてカウントされてしまうからだ。

【3】みなしOK

過去に実施したテストケースで、今回の開発に影響しないテストケースをテストせずに成功ステータスとすること。
例えば、小売Webシステムでクレジットカード注文の仕様変更があった場合、クレジットカード注文機能のテストは行うけれども、今回の修正に全く無関係なコンビニ注文のテストは「みなしOK」として成功ステータスとする場合があげられる。

実際のテストでは、すぐにテストケース数が膨れ上がってしまうために、工数や納期を考えるとテストケースを間引く必要がある。
しかし、「みなしOK」の判断は、システムの仕様や過去の障害履歴などを十分に考慮して判断しなければ、テスト漏れになってしまう危険性があるので注意すべき。

【4】ブロッキングバグ

ブロックしたテストケースの発生源となるバグ。
文字通り、ブロジェクトの進捗をブロックしてしまい、プロジェクトを危険な状況に陥らせるバグを指す。

実際のテストでは、テストするほどバグがどんどん増える時が多い。
すると、失敗するたびにその10倍ぐらいのテストケースがブロックされてしまい、すぐにテスト不能に陥ってしまいがち。
つまり、バグが多すぎて、どれがブロッキングバグなのか分からなくなる時が多い。
そうなると、バグ修正できてないのに、無駄にテストを先に進めてテスト工数を浪費したり、デグレを発見したりして、テストチームのモチベーションを下げてしまう。

だから、テストに失敗するたびに、ブロッキングバグに目印を付けて、バグ修正はブロッキングバグを最優先に行って、テストの進捗を妨げないようにするのがテスト戦略の基本。

TestLinkには、失敗したテストケースをBTSと連携する機能があるので、テスターと開発者が相互にバグ検証とバグ修正を連携するワークフローが自然にできる。
だから、バグ修正の優先順位さえ間違わなければ、テストはスムーズに進むはず。

【5】同種バグ(類似バグ)

既存バグと同一原因の残存バグを指す。
例えば、画面のあるプルダウンのエラーチェックにバグがあれば、他画面でも同様のバグがあるだろう。

実際のテストでは、一つのバグの周辺には必ず他のバグが存在する確率が高い。
何故なら、バグを埋め込んでしまった原因は、開発者が仕様を完全に理解していなかったり、誤った実装方法を使い回していたりする時が多いからだ。
つまり、開発者の作業そのものに問題がある時が多い。
だから、同種バグを探すには、バグの原因分析が非常に重要になる。

【6】みなしバグ

ブロッキングバグの同種バグ。
例えば、みなしNGのテストケースのバグがあるだろう。

ブロッキングバグを見つけたら、そのテストケース周辺やその機能の周辺には、他のバグが紛れ込んでいる可能性が高い。
テスターは、ブロックを上手に使いこなしながら、限られた工数で数多くのバグを見つけ出さねばならないのだ。

【7】周辺テスト

ブロッキングバグ修正後、ブロッキングバグに関係する成功ステータスのテストケースを回帰テストしてみること。
例えば、カート削除のバグを修正後、既に成功ステータスで実施済みのカート表示やカート投入の機能を再テストする場合を指す。

実際のテストでは、既に成功ステータスのテストケースを再テストする必要はないけれども、回帰テストでバグ修正のデグレがないことを検証したいものだ。
TestLinkでは、テスト結果をビルド単位に別管理できるので、回帰テストの結果を履歴管理できる利点がある。

【8】後追いテスト

リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、優先順位が低くて未実施のテストケースを実施したり、回帰テストを行うテスト手法を後追いテストと呼ぶ。
後追いテストの目的は、更なる品質強化だ。

出荷前の時期になると、プロダクトリスクが発生するような重大なバグは殆ど潰されているが、エラー文言の修正だったり、UIの改善など、細かな作業はまだまだあるはず。
だから、空き時間を使って、細かなバグ修正とバグ検証を行い、システムのマイナーバージョンアップのリリースへつなげる。

※Nakaさんからのアドバイスによれば、後追いテストで、致命的なバグが見つかったら、販売を止めるか、判定基準も必要。致命的なバグが出た場合の事も考えて、緊急報告体制を引いておく事も大切、とのこと。

【9】五月雨テスト

開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
仕様変更が次々にやって来て、小刻みに検証せざるを得ない場合に用いる時が多い。

このテスト手法は、まさにアジャイル開発そのもの。
開発チームが単体テストまで開発が完了したら、すぐにテストチームがそのモジュールをテストし始めて、テスト結果を開発チームへフィードバックしていく。

TestLinkをアジャイル開発に当てはめるやり方は、「脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所」に詳しく書いた。
つまり、テスト計画をイテレーションと見なして、2～4週間のサイクルで順次テストしていく戦略を取る。

TestLinkを上手に使いこなせていない人の話を聞くと、テスト計画の単位が良くない。
例えば、テスト計画が1個しかなく、数千ものテストケースを実施しようとしていて、何ヶ月経ってもバグが直らず、いつまでたってもリリースできない状況が多い。
まずは、全てのテストケースを最低1回は実施できるように、複数のテスト計画に分割し、テスト計画に含むテストケース数をせいぜい500個以下に抑えて、順次テストしていくアジャイル開発っぽいテスト手法が最も確実だと思う。

【10】受入テスト

発注者が納品モジュールのバージョン単位でテストしていく手法。
まさに受入テストなのだが、開発チームのテスト手法である五月雨テストとは異なる。

TestLinkによる五月雨テストでは、テストケースを複数個のテスト計画にグループ化し、テスト計画をイテレーションと見なして、順次テストしていく。まずは全てのテストを通すことを最優先にするので、テスト結果は1個のビルドで管理している時が多いだろう。

逆にTestLinkによる受入テストでは、受入テストケースを1個のテスト計画にアサインするが、納品モジュールの単位でテスト結果を履歴管理する。実際は、TestLinkのビルドを納品モジュールのバージョンと見なして、納品モジュールのバグを記録しておく。
理由は、納品モジュールがバージョンアップするに従って、どこまで品質が保証されているか、明確に管理したいからだ。
TestLinkのVer1.8以降では、複数のビルドをまとめたテスト結果を表示できるので、使い易くなっているようだ。

つまり、発注者がTestLinkを使う場合は、TestLinkのテスト計画とビルドの関係が1対Nになるので、五月雨テストの時と異なるのに注意する。

TestLinkによるテスト管理を使いこなせれば、ソフトウェアテストや品質管理の技法が自然に身に付く。
是非、TestLinkを使ってみて、足りない機能はTestLinkをカスタマイズして機能改善してみて欲しい。