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

TEF関西のNakaさんから「後追いテスト」というテストの用語を教えてもらったのでメモ。

【元ネタ】
ソフトウェアテスト標準用語集 日本語版Ver 1.3

まず、ソフトウェアテスト標準用語集 日本語版Ver 1.3には「リスク」「プロダクトリスク」「プロジェクトリスク」の用語解説がある。

テスト工程での「リスク」は「将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。」という意味で定義されている。

プロダクトリスクとは、「テスト対象に直接関係するリスク」。
プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」

つまり、テスト工程のリスクを、プロダクトリスクとプロジェクトリスクに厳格に分けている点が重要だ。
組み込み製品なら1回リリースするために数千～数万のテストケースをクリアする必要があるが、この時のリスクとして、テスターとPGが不足しているためにテストの進捗が悪くなるリスクはプロジェクトリスク。
テストできずにリリースして、後で品質問題に直結するリスクがプロダクトリスク。

ソフトウェア開発の基本は、プロダクトリスクの高い機能を優先して開発することだ。
そして、RedmineやTestLinkなどの各種ツールを駆使して、スタッフ不足や複雑な変更管理などのプロジェクトリスクを技術力でカバーするのが、プロジェクト管理の醍醐味だと思う。

ここで、「後追いテスト」とは「リリース後にプロダクトリスクの低いバグ潰しのテストを行う」意味らしい。

つまり、「リリース前のテストではプロダクトリスクの高いバグを最優先で潰すが、プロダクトリスクの低いバグは残したままリリースせざるを得ない。だから、リリース後の後追いテストで、プロダクトリスクの低いバグを潰していく」意味だと思う。
この手法は、特に新規顧客に対する受託開発の初めてのカットオーバーでよく使われるだろう。

例えば、新規顧客の受託開発を請け負った場合、顧客の要望を吸い取る要件定義がすごく難しい。
理由は、顧客の距離感が分からないからだ。
つまり、顧客が欲しいと思う機能は実際に使ってみたら違っていたり、開発チームが顧客の業務や会社の体制を完全に理解できないために要件を勘違いしたりする場面はいくらでも発生する。
だから、結合テストで実際に動かし、受入テストで顧客に初めて届けた時に、契約していたシステムと違っていた、という場面が多々発生しやすい。

その場合、機能も大事だが納期もすごく重要な時が多い。
特に業務システムは、他の運用中のシステムや会計システムと連動する時が多いから、納期の厳守がリリースの制約条件になる時が多い。

従って、開発方針としては、プロダクトリスクの高い機能を早く開発して、顧客に早めに叩いてもらい、フィードバックしてもらう手法がBetterだろうと思う。
そして、プロダクトリスクの低い機能やバグは、リリース後に後追いテストして、小刻みにリリースしていく開発スタイルになるだろう。
この時に、本番運用と機能追加のコードラインを別々に管理する並行開発が十分に機能すれば、後追いテストという手法を故意に選択することもできるだろう。

TestLinkでは、テスト実施結果をビルド、実施するテストケースをテスト計画という概念で別管理しているため、後追いテストの管理がやりやすい。
例えば、テスト計画に「Ver1.0リリース」「Ver1.1リリース」などのように、後追いテストのテストケースを別途分けたり、リリース済みのテストケースを使ってデグレしないか確認するために回帰テストすればよいだろう。

テスト工程のプロジェクト管理は、アジャイル開発や従来のソフトウェア開発にはなかった特有のマネジメント手法が存在しているように思う。