TestLinkのアンチパターン

TestLinkでテスト管理をしてみた経験、他の人から聞いた話から、TestLinkを運用したけど使いこなせない症状にパターンがあるような気がした。
それらをアンチパターンとしてまとめてみた。

【元ネタ】
TestLinkがExcelのテスト仕様書よりも素晴らしい点

TestLinkを運用して気付いたことpart4～TestLinkの概念を再考

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

TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理

TestLinkを運用して気付いたことpart7～要件カバレッジは難しい

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

TestLinkを運用して気付いたことpart9～後追いテスト

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

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略

TestLinkを受入テストで運用する方法

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

TestLinkのベストプラクティス集: プログラマの思索

【1】乱発されたバグ

テストすればするほどバグが出る状況。
大量のテストケースをとにかく全部通そうと強引にテストを進めると、似たようなバグがどんどん出てくる。
納期が迫っていて、プレッシャーがあるとよく起こる。

TestLinkを使う場合、ブロックを上手に使うことが重要だ。
テストに失敗した場合、依存するテストケースにも同様のバグが紛れ込んでいるので、NGになる可能性が非常に高い。
バグを直さなければ、いくらテストしても工数の無駄だ。
だから、NGになったらブロックを使って、依存するテストケースは一旦テスト保留として飛ばす。
あるいは、テストしなくてもこれは同じブロッキングバグのせいでNGになると分かれば、みなしNGにしておく。
そして、ブロッキングバグを区別して、同種バグを判断し、みなしバグはテストしない方針でやるべき。

失敗したテストケースに依存するテストケースをテストしないようにすれば、バグが乱発されることはないし、着実にテストを進めることができるはず。

【2】放置されたバグ

バグが多発して放置された状況。
テストするほどバグが出て、ブロッキングバグは一つずつ検証して潰すものの、同種バグを検証し切れていない状況が多いだろう。

ブロッキングバグの原因は他のバグと関係している時が非常に多い。
つまり同種バグの分析ができていないのだ。

ブロッキングバグが出た場合、必ずバグの原因分析を行い、他の機能にも同様のバグが無いか、他のバグと同じ原因ではないか、根本的に分析すべきだ。
そうすれば、バグの真の原因は絞りきれて、一つのバグを潰せば複数のバグも直るというケースで同種バグを潰すことができる。

【3】モグラ叩きのバグ

発見したバグを潰したのに、同じような原因のバグが出たり、他のバグが出たりする状況。
いわゆるデグレも同様。
この状況が多発すると、いくらバグを直しても不安になるため、テスターも開発者もモチベーションが落ちる危険な状況。

原因はブロックを使っていないこと、同種バグを潰しきれていないこと、TestLinkのビルドで回帰テストを管理していないことにある。
ブロッキングバグを潰したら、ブロッキングバグに依存するブロックされたテストケースやみなしNGのテストケースのみ再検証する運用にすれば、検証範囲を絞りきれるので、確実にテストで潰せる。
あるいは、ブロッキングバグを潰したとしても、同種バグがないか、他の機能に影響がないか、バグの原因分析をきちんと行えば、確実にバグは減るはず。
あるいは、回帰テストのテスト結果をTestLinkのビルドで別管理にすれば、どのモジュールでバグが出たのか分かるから、どのソースの修正でバグを入れ込んだのか探りやすくなる。

結局、テストやバグ検証というワークフローがきちんと管理されていない点に根本的な問題があると思う。

【4】テストが終わらない

納期が迫っているのに、テストケースが多すぎて、リリース予定日までにテストが終わらない状況。
テスト戦略、テスト計画がきちんと考慮されていないと陥りやすい。
つまり、テストケース数と工数がアンマッチなのだ。

そもそもテスト工程は、実際に動くモジュールがなければテストできないから、どうしてもテスト開始日は遅れがちになりやすい。
又、単体テストだけでなく、結合テスト、システムテスト、受入テスト、負荷テスト、探索テストなどいろんな種類のテストをしなければ、品質を保証できたとは到底言えない。
すると、たった1個のシステムをリリースするために数千～数万ケースも消化しないといけないから、テスト戦略がなければ、未テストのままリリースしてしまう危険もある。

対策としては、優先順位の低いテストケースは後回しとし、機能単位に確実にテストでバグを潰していく戦略が基本だろうと思う。
つまり、今回の開発に無関係の機能のテストはみなしOKとしてテストはしないとか、プロダクトリスクの低いテストケースは製品ベータ版が出た後に後追いテストを使ったりして、テストケースそのものを間引く。
あるいは、五月雨テストを使って、仕様変更を開発できたらすぐにテストチームへ回し、検証してもらい、順次開発とテストを繰り返していく。

テスト計画を立ててテスト仕様書を作った時点で、テストケース数とテスターの人数から、どれくらいの期間がかかるのか、は見積ができるはず。
だから、限られた工数の中でどんな観点でテストするのか、どのテストを優先するか、どのように品質を高めていくか、というテスト戦略が重要になる。

【5】巨大なテスト計画

TestLinkのテスト計画が1個しかない状況。
TestLinkのテスト計画に全てのテストケースを放り込んだ場合に相当する。
すると、テスト計画に含まれるテストケース数は数千～数万になるため、1個のテスト計画を終わらせるのに数カ月もかかってしまうだろう。
そうすれば、結局未テストのままリリースする危険がある。

TestLinkはある意味Scrumのバックログ管理に似たような機能があるから、それを意識して使えば良い。
つまり、テスト仕様にテストケースをバックログのように貯めておき、テスト計画をスプリントと見なして、テスト仕様からテストケースをテスト計画へアサインし、順次テストしていくのがリスクが低いと考える。
つまり、プロダクトバックログから、次スプリントでリリースするストーリーカードを取捨選択して、1ヶ月間のサイクルで開発していくやり方と同じだ。

従って、テスト計画をせいぜい数百ケースに分割し、アジャイル開発のように順次テストしていく戦略が最も良いと思う。

【6】バージョンのないテスト

テスト結果が1パターンしか残していないので、どのビルドモジュール・納品モジュールでテストしたか、区別していない状況。
だから、テストでOkだったのに後でテストしたらNGだった、というように、デグレが起きる場合もある。

TestLinkの使い方が分からない、という人に多いと思う。

TestLinkではビルドという概念で、同一のテストケースに対するテスト結果を区別して管理できる。
従って、納品されたモジュール単位でビルドを変えてテスト結果を残せば、どのバージョンで発見したバグが次のバージョンで直されたのか、を区別できるから、デグレが起きにくくなる。

バグ修正の時にバグを入れ込んでしまう危険性が高い、という事実はソフトウェアテストの観点ではよく知られている。
だから、テスト結果をきちんと区別して管理するのは非常に重要なのだ。

【7】一塊のテストケース

テスト仕様書のフォーマットがシンプルすぎて、テストケースに事前条件や事後条件の区別がなく、テストケースとテスト結果欄しかない状況。
あるいは、テストケースが機能やテスト目的の単位で区別されていない状況。
すると、テスターがテストケースを理解しにくいので、テストの品質が落ちやすい。

テスト工程では大量のテスターが投入される場合が多いので、システムの仕様を知らないテスターが多い。
すると、テストケースの品質が悪ければ、本来存在するバグを見つけられなかったり、デグレが起きたりしやすい。

テストケースはユースケースのように、事前条件・ステップ・期待値の3つで分けて書くべき。
特に、ブロックを使いたい場合、事前条件を明確に詳しく書いておかないと、テスターはブロックしてよいのかどうか判断しにくい。
だから、TestLinkのテストケースの書式に合うようにテストケースを作りこめばいい。

又、TestLinkでは、テストスイートを使ってテストケースを分類するのも重要だ。
サブシステム、大中小の機能、テストの目的などのテストケースの属性は、テストスイートを使って階層化すれば、テスターはテスト範囲を理解しやすいし、ブロックする範囲に気づきやすい。

似たようなアンチパターンとしては「バージョンがテストスイートにある」「結合テストやシステムテストなどの工程がテストケースにある」などがある。
これらのアンチパターンは、バージョンや工程という概念とテストケースの対応付けができていない場合によく見られる。
バージョンや工程という概念が何を意味しているのか、を考えれば、TestLinkに落とせるはず。

まず、結合テストやシステムテストなどの工程は、TestLinkのテスト計画にアサインすべきだ。
理由は、各工程に属するテストケースの観点こそがテスト計画でありテスト戦略だからだ。
従って、結合テスト、システムテスト、負荷テスト、探索テスト、受入テストなどのようにテスト計画を順次実施していくやり方が最もスムーズに進むだろう。
ここで、例えば、結合テストに含まれるテストケース数が1千ケースを超えるぐらい多いならば、サブシステム単位の結合テストに分割して、「結合テストPh1」などのように結合テスト工程そのものを分割すると良いだろう。
そうすれば、テスト計画をイテレーションのようにアジャイルにテストできる。

次に、バージョンはある時点のビルドモジュールのスナップショット。
バージョンはTestLinkのテスト計画に対応付ける場合と、TestLinkのビルドに対応付ける場合の2パターンがある。
前者はバージョンをテスト計画に対応付けた場合、五月雨テスト、つまり、アジャイル開発そのものになる。
例えば、Ver1.0はショッピングシステムの会員機能、Ver2.0はショッピングシステムの商品機能、Ver3.0はショッピングシステムの注文機能などのように、バージョンアップするたびにテスト計画を実施するようにすればいい。

後者はバージョンをビルドに対応付けた場合、受入テストのスタイルになる。
例えば、発注者がSIから納品されたモジュールを納品バージョン単位にテスト結果を残す時に、一つのテスト計画に対し、テスト結果をビルドで管理すれば、前回発見したバグが今回のバージョンで直されているか、一つずつチェックすることができる。
つまり、バージョンは納品モジュールのビルド番号に対応付けることができる。

TestLinkのテスト計画、ビルド、テストスイートの構造にテスト仕様書を合わせれば、TestLinkのベストプラクティスを使えるから、テストがより効率的になるはず。

【8】テスト漏れ
全てのテストケースを通したのに、レビューでテスト漏れが発覚したり、リリース後にテスト漏れが原因で障害が発生した状況。
テスト漏れの原因は色々あるが、要件カバレッジの観点がないこと、TDDだけに頼っていてテスト戦略そのものがないことが多いのではなかろうか？

前者は、元々の要件や仕様を全てテストできていなかったことにある。
実際にテストケースと要件を紐付けながらテスト仕様書を作ってみると、要件をテストで全て網羅するのは非常に難しい。
何故なら、要件や仕様とテストケースの関係はN対Nになるため、複雑で、整合性を取るだけでも大変だからだ。

又、XPが生み出したテスト駆動開発は確かに優れたプラクティスだが、テストはそれだけではない。仕様を満たすためのテストだけでなく、ユーザの観点での受入テスト、バグを探す探索テスト、性能要件をチェックする負荷テストなど、テストにもいろんな種類がある。
それぞれの観点でテストして品質を高めていくには、どのテストを優先して、いつどの順番でテストしていくか、などのテスト戦略が重要になってくる。

【Excelの仕様書の弱点】

TestLinkのアンチパターンをまとめてみると、Excelの仕様書では限界があることに改めて気づく。
Excelのテスト仕様書の弱点は以下があげられると思う。

・イテレーションの概念がない。
・バージョンの概念がない。テスト結果の欄が一つだけだから。
・バグIDを記述する欄がない。
・ブロックする運用がない。
・要件管理IDを記述する欄がない。
・テストケースの依存関係を記述する欄がない。

これら弱点をカバーするために、テストケースの横に項目を追加していくと、テスト仕様書はどんどん複雑になっていく。
結局、Excelでテスト管理システムを作りこんでいるようなものだ。
肥大化したExcelファイルほど使い辛いものはない。

【まとめ】

TestLinkのアンチパターンから、テストにはプログラミングと違う構造があるのに気づく。
一つ目は、テストは回帰テストが多いことだ。
例えば、システムがバージョンアップする度に、過去のバージョンのテストケースを使い回したりする。
あるいは、仕様変更で対応したものの品質に不安な機能は、過去のテストケースを使い回して余分に回帰テストでデグレしていないことを検証してみる。

つまり、過去に作ったテストケースはその後の運用保守でも使う場合が多い。
又、本番稼動しているシステムの仕様をリバースエンジニアリングする場合に、過去に使用済みのテストケースがあれば、非常に役立つ。

だから、Scrumのバックログ管理のように、TestLinkのテスト仕様でテストケースをどんどん貯蔵して、必要な時にテスト計画へ割り当てる手法が編み出されたのだろう。
更に、XPの継続的インテグレーションのように、回帰テストを自動化できる機構があるとなお良いのだろう。

二つ目は、バグの原因分析が重要なこと。
バグは魚の目のように、根元から直さないと、いつまで経ってもバグは残る。
更に厄介なのは、バグ修正する時に、別のバグを埋め込んでしまう危険性も高い点もある。
だから、バグが発生した原因を突き詰めて、バグの周辺にある他のバグ、あるいは同じ原因のバグを徹底的に潰すのが品質保証の要諦ではないか。

つまり、ブロッキングバグを見つけたら、その同種バグを徹底的にあぶり出すのが非常に重要なのだ。

TestLinkを使い倒すと、テスト管理や品質管理の色んなノウハウがあることに気づくだろう。