TestLinkを運用して気付いたことpart2～ビルドと要件管理機能

先週、TestLinkのメーリングリストで、コミッタの川西さんとTestLinkのUI改善や運用方法について熱く議論した。
その議論で考えたことについて書いてみる。

【参考】
TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

TEF有志によるTestLink日本語化プロジェクト - TestLink日本語版で始めるテスト管理システム(簡易マニュアル)

僕はTestLinkを3ヶ月運用してみて、Redmineと同様にTestLinkは僕のプロジェクト運営に欠かせないツールになった。
僕のチームでさえも、単体～システムテストのケース数は数千オーダー。
もはやExcelのテスト仕様書で管理するのは非現実的。
しかし、テスト工程をExcelで管理しているプロジェクトが殆どで、どのプロジェクトも結合テスト以降の開発に苦労している。

特に、テストでNGとなったケースを一つずつバグ修正して品質を上げていくプロセスは、バグ修正者とテスト担当者のパイプラインをPLがどれだけフォローできるかにかかっている。

TestLinkでテスト担当者がテストでバグ出しして、Redmineで開発者がバグ修正していくパイプラインができた今では、TestLinkとRedmine無しのSW開発は考えられない。

しかし、TestLinkのUIは使いづらい機能があり、使いこなせない機能がある。
川西さんから、TestLinkの「ビルド」という概念と要件管理機能を改めて教えてもらった。

TestLinkにあるビルドの概念は下記の通りだ。

1.ビルドごとにテストケースをアサインすることはできない。

2.ビルドは、テスト計画にアサインされたテストケースを回帰テストで管理するためにある。
　(１の機能が実装されている理由に相当する)

#実際の運用のイメージ
　最初はビルドを1個だけ追加する。
　→ビルドに紐づいたテストケースをテストする
　→リリース時にビルドをCloseして、テスト結果を変更できないようにする。
　→2回目のテスト開始時に、新たなビルドを追加する。
　　テスト計画にアサインされた全テストケース(1回目のテストで成功になったケースも含む)をテスト開始。
　　1回目のテスト結果は無関係。
　→以下繰り返し。

3.イテレーション単位にテストケースを変更してリリースするならば、そのたびにテスト計画を作って、テストケースをアサインする。

#実際の運用のイメージ
　イテレーション1は機能A、イテレーション2は機能Bをリリースする計画を立てたと仮定する。

　イテレーション1を開始
　→機能Aのテストケースをテスト計画1にアサインする
　→テスト計画1へビルド1をアサインする
　→機能Aのテスト実行
　→機能Aのテスト結果が全て「成功」になったら、ビルド1をCloseする
　→イテレーション1をリリース
　↓
　→イテレーション2を開始
　→機能Bのテストケースをテスト計画2にアサインする
　→テスト計画2へビルド2をアサインする
　→機能Bのテスト実行
　→機能Bのテスト結果が全て「成功」になったら、ビルド2をCloseする
　→イテレーション2をリリース

つまり、XPやScrumのイテレーションはTestLinkのテスト計画に相当し、TestLinkのビルドはXPの継続的インテグレーションで行う統合ビルド(実際のシステムのビルド)と同等。

例えば、TestLinkのビルド＝Hudson(CIツール)のビルド番号として運用できる！
この例を聞いて、心底、ビルドの概念を理解できた。

もう一つは、TestLinkの要件管理機能。
TestLinkでは、要件をCSVインポートでき、その要件をテストケースと紐づけることができる。
テスト結果画面では、要件の単位でNGのテストケース数などをリアルタイムに見ることができる。
つまり、要件とテストケースのカバレッジを見れる。
この機能は、TracやRedmineに無い素晴らしい機能。

しかし、TestLink上で要件からテストケースを1個ずつ作成して、要件とテストケースを紐付けするのは、ケース数の桁が数千～数万の場合、非現実的。

今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を追加している。
理由は、テストの目的や観点を明確にして、お客様に説明するため。
つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは揃ってる。
狙いは下記のトレーサビリティ。

要件(TestLink)→テストケース(TestLink)→【チケット】(Redmine)←ソース(Subversion)

上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合はテスト仕様書の作成工程で潰せると思う。

今、Redmine＋TestLinkで結合テストや受入テスト、障害修正は非常にスピードアップできている。
しかし、バグ発生の原因を探ると、確かにPGMミスもあるが、仕様漏れや設計漏れ、他機能への影響の考慮漏れ、など、上流工程や変更管理の品質の方に問題がある。

その対策として、TestLinkの要件管理を使いたい。

残念ながら、TestLinkの要件管理機能は現場で使えるレベルではない。
しかし、Redmineと同じくTestLinkには更なる可能性があると思う。