TestLinkを運用して気付いたことpart10～テストの制約条件

TEF関西のNakaさんの話を聞いて考えたことをメモ。

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

普通のプロジェクトは結合テストで火を噴く。
理由は、結合テストで初めて、システムが稼動するのを顧客も開発者も見れるから。
そこで、初めて、要件漏れ、認識相違、仕様漏れに気付く。

でも、それだけの理由だけではないという指摘を受けた。

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

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

実際のテスト、特に結合テスト、システムテスト、受入テストのようにプロジェクト後半になるにつれて、テスターやバグ修正担当者の不足、間近に迫る納期という工数不足、つまりプロジェクトリスクがすごく大きい。
テスト工程はプロジェクト後半のため、元々リソースが少ない。

だからといって、逆にテスターを増やしたとしても、ブロッキングバグが多発してみなしバグが増えれば、いくらテストしても無意味だ。

また、開発が遅れに遅れて、テスト期間がそもそも短い場合、リリースできる品質をテストで確かめることができず、全ての機能をテストできないままリリースせざるを得ないかもしれない。
その場合、リリース後にたくさんの苦情が開発チームに押し寄せる。

つまり、テストには制約条件が非常に多い。

まず、テスト計画を立てた時、与えられた期間と手持ちのスタッフ数から、実施できるテストケース数の上限という制約条件がある。
この上限を超えたテストケースを作った場合、スタッフを増やして徹夜させて納期に間に合わせるか、あるいは、納期を遅らせてテスト工数を確保するか、という選択を現場リーダーは決断せねばならない。
ここで、アジャイル開発を実践しているならば、スコープを削ることで品質と納期を確保する選択肢も取れるだろう。

でも、アジャイル開発であろうとも、残りの期間でテストしてリリース可能な品質を保証できる機能は、上記の上限から限られるのだ。

極端には、テスト計画を立てた時点で、そのプロジェクトは既に死んでいる場合もあるのだ。
つまり、テストケースが多すぎて工数を確保できず、プロジェクトリスクをどうやっても解決できないプロジェクトはありうる。

次に、テストの失敗率から、ブロックされるテストケースが増えすぎてテストできない状態になる上限がある。
つまり、ブロッキングバグがある上限を超えると、殆ど全てのテストケースがみなしバグとなってしまい、テスト不能になる状況が考えられる。

だから、バグを発見したら、どのバグを最優先で直すか、優先順位を付けてブロッキングバグの修正に最優先に対応する。
あるいは、結合テストでそもそもブロッキングバグが出ないように予防しておくべきだろう。

実際は、障害件数をあらかじめ予想しておき、障害修正工数や再テスト工数も予測しておけば、テスト実施のクリティカルパスが見える。
そこから、どのブロッキングバグを最優先で直して、次にどこのテストケースをテストするか、というふうに先を見通して手を打たねばならない。

上記のプロジェクトリスクを解決できずにリリースした場合、顧客からの膨大なクレームや不良品による返品などといったプロダクトリスクで跳ね返ってくる。

テスト工程のプロジェクト管理が上流工程のそれよりも難しいのは、上記のような制約条件に対するリスク管理が非常に難しいからだろう。

TestLinkでは、テストケースのカスタムフィールドに予定工数やテスト実施予定日を入力すれば、テスト計画の総予定工数をあらかじめ予測できる。
また、TestLinkのテストケースの情報を出力してTestLinkCnvMacroに取り込めば、Excelで解析することができる。

そこから、リスクを洗い出し、プロジェクトリスクやプロダクトリスクに分ける。
おそらく、プロジェクトリスクには、アジャイル開発のプロジェクト管理の基本であるスコープ・納期・コストで対応すればいいだろう。
プロダクトリスクには、優先順位付けして最優先で対応する戦略を取ればいいだろう。

テスト工程のプロジェクト管理には、上流工程とは異なる特有のマネジメント手法があるのだと思う。
色々考察してみたい。