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

かおるんさんのTestLink経験談を読んで、TestLinkの概念をもう一度考え直した。
以下メモ書き。

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

TestLinkで重要な概念は「テスト計画」「ビルド」「テスト仕様」だと思う。

「テスト仕様」はテストケースの貯蔵庫。
Scrumのプロダクトバックログに相当する。

「テスト計画」はテストケースをイテレーションの単位でグループ化したもの。
Scrumのスプリントバックログ、XPのイテレーションに相当する。

「ビルド」は「テスト計画」の実施結果。
つまり、回帰テストの実施結果そのもの。
普通は、テスト対象モジュールのビルド番号、製造番号に相当するようだ。

概念モデル上では、「テスト計画」と「ビルド」は1対多の関係になる。
テスト計画を2回以上実施したいならば、ビルドを2個以上作ればいい。
この関係があるおかげで、回帰テストを管理しやすくなる。
回帰テストを自動化できる環境ならば、ビルドへテスト結果を流し込めばいい。
回帰テストは、デグレ防止にもなるから、システムの品質を更に強化してくれる。

運用上は、「テスト仕様」にあるテストケースをリリース計画に基づいて、どのイテレーションでテストするか、「テスト計画」へテストケースをアサインしていく。
この作業が真の意味でのテスト計画と言っていいと思う。

リリース計画、要件の優先順位付けなどから、どのテストを最優先に進めるか、手間をかけてでもテストすべきか、というマネジメントそのものになる。
更には、1次開発でバグを多く出した機能のテストケースがあるならば、2次開発以降でそのテストケースを再利用して、手間をかけてでも再テストする、などと言った戦略も取ることができる。

普通のシステムをリリースするまでの単体～受入テストまでの全テストケース数は軽く数千～数万になるため、テスト計画へ上手に分割する必要がある。
そうしなければ、全てのテストケースを実施するのに数ヶ月かかるだろう。
最悪な場合は、全てのテストケースを実施しきれないだろう。

たとえ、テスト工程を制御できているチームであろうとも、テスト工程で実施するテストケースを間引いて手を抜いていいわけではない。

TestLinkでテストケースの管理や実施結果の管理を始めると、テスト工程というプロセスの品質が今までいかにおろそかだったか、よく分かる。
つまり、全テストケースを実施できずに、品質保証すらできずにリリースしていなかったのか？という疑問が湧いてくるだろうと思う。

数千～数万のテストケースと実施結果を管理するのは並大抵の苦労ではないと思う。