TestLinkにあるアジャイルの概念

下記の記事を読んで気づいたことをメモ。

【元ネタ】
TestLinkを検証しました ― ありえるえりあ

【引用】
テストケースの管理と、テスト計画(=テスト実施の記録)の管理のふたつの軸があるのがポイントです。
RDBアプリ風に言えば、前者がマスター(リソース)、後者がトランザクション(イベント)的な構造です。
テストケースは手順と期待値の記述で、何度も実施されればその度ごとに結果レコードができます。
テストケースの1レコードに対して、実施結果のレコードは1対多の関係で存在します。

テストケースと実施結果が1対多の関係になるのは、言われてみれば自然で当り前の構造なのですが、バグトラッキングシステム(BTS)とは違うんだという現実に改めて気づきました。
昔、wishlistもBTSで管理している話を書きました(http://dev.ariel-networks.com/Members/inoue/wishlist-management)。
実を言うと、テスト管理もBTSでできるのでないかと漠然と考えていたことがあります。
テストの実施をテストエンジニアにアサインして、実施後に結果がでるという一連の流れがBTSの一連のフローと似たようなものだと思っていたからです。
実に浅はかでした。
テスト管理ツールにはテスト管理ツールの存在意義がありました。先人の知恵を無視してはいけません。

【プロダクトバックログとスプリントバックログの違い】
上記の記事のポイントは2つある。
一つは、テストケースとテスト結果は1対多の関係になること。
もう一つは、テスト管理はBTSのワークフローでは制御しにくいこと。

前者は、TestLinkにある「テスト仕様」と「テスト計画」の概念の違いと同等だ。
(正しくは、「テスト仕様」と「ビルド」である)
つまり、Scrumで例えるならば、TestLinkの「テスト仕様」はScrumのプロダクトバックログ、「テスト計画」はScrumのスプリントバックログに相当する。

Scrumでは、顧客からの改善要望や障害報告などは、まず、プロダクトバックログに全て放り込まれる。
そして、スプリント計画を作成する時に、どのスプリント(XPのイテレーション)でその要望を実現するか、を吟味する。
プロダクトバックログにある要望がスプリントに追加されて、そのスプリントで何をリリースするか確定したら、スプリントバックログが確定される。
つまり、プロダクトバックログは、スプリントにアサインされていない要望の貯蔵庫なのだ。

同様に、TestLinkのテスト仕様もテストケースの貯蔵庫と言ってよい。
テスト仕様にあるテストケースから、実施するテスト計画へテストケースを追加していく。
テスト計画に追加されたテストケースは、実施予定のテストケースであり、テスト仕様のテストケースと実体は同じでも、意味合いは大きく異なるのだ。

Scrumのようなアジャイル開発では、頻繁な改善要望に対応するために、イテレーション(スプリント)に入れる前の要望を管理するプロダクトバックログという概念が必要になったと思われる。

つまり、プロダクトバックログで要件管理を行っているのだ。
スプリント計画を作る時に、プロダクトバックログにある要望を優先順位付けするという作業が必要になる。
この作業が本来のマネジメントでもある。

後者は、素のBTSには、プロダクトバックログつまり要件管理の概念が無いことから生じるのだと思う。
BTSは障害報告票をデジタル化して運用するために作られたので、プロダクトバックログのように障害報告を貯蔵する仕組み(つまり要件管理)の無いBTSでは運用しづらいだろう。

特に、単体・結合・総合・負荷・受入テストなど全てのテストケース数を合計したら、ちょっとした業務システムでも、テストケースは軽く1万ケース近くに膨れ上がるだろう。
だからこそ、２～４週間以内に完了できるテストケース数に抑えないと、回帰テストを実施できないだけでなく、全テストケースを流し切ることさえできないだろう。

つまり、テスト仕様には1万個ものテストケースを一旦貯めておき、複数回のリリース(開発)を前提として、複数個のテスト計画を順次実行する運用にしなければ、実施できないテストケースが出てしまい、システムの品質以前に、テスト工程に大きな問題が出ることになる。

僕としては、開発とテスト工程のワークフロー管理は、BTSとTestLinkで使い分ければよいと考える。
無理して、一つのツールで運用する必要も無い。

ツールでプロセスを改善していく。
ツールでアジャイル開発のハードルを下げられればいい。