TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略

チケット駆動開発にTestLinkを導入してテスト管理してみて、テスト戦略みたいなものをぼんやりと感じた。
以下メモ書き。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所

テスト手法の概念をTestLinkで説明する: プログラマの思索

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkを運用して気付いたことpart4～TestLinkの概念を再考: プログラマの思索

TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索

TestLink・BTS・SVN・Hudsonの関連構造: プログラマの思索

【1】Redmineによるチケット駆動開発はとてもアジャイルに開発できるけれど、システムテストや受入テストの進捗管理はやりにくかった。
テスト工程の進捗管理は、テストケースの実施数・成功数・失敗数の予定・実績を比較することにあるけれど、Redmineチケットはテストケースと一致しないからだ。
だから、TestLinkを導入して一番良かったのは、テスト結果集計画面で、リアルタイムにテストの進捗を見れるようになった事であり、それから早期に是正対策を取るのが可能になった。

TestLinkがExcelなどの他のテスト管理ツールよりも良い点の一つは、Redmine・Trac・Mantisなどの既存のBTSと連携する機能がある事だ。
この機能によって、テストケースに失敗した場合、BTSチケットにバグの内容を書き込んで、バグ修正とバグ検証をペアプロのように作業できるようになる。

SW開発で最も難しい局面は、結合テスト(Integration Test)・システムテスト(System Test)・受入テスト(User Acceptance Test)などの各テスト工程で頻発するバグをいかに直していくか、にある。
バグ修正＆検証フローは実はとても複雑なワークフローであるからだ。

脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－4　TestLinkのバグ検証とRedmineのバグ修正の連携フロー 」に書いたように、バグは修正して終わりではなく、バグ修正内容を検証して、更に失敗したテストケースが成功した所までの作業を含む。
そして、この作業は、バグを発見し検証するテスター、バグを修正する開発者、リリース作業を行うライブラリアン、そして全てのプロセスを監視するプロジェクトリーダーの4人が関わるので、そのやり取りだけで忙殺されやすい。

従来は、この作業内容をExcelの障害報告書に記載して、紙ベースで管理し、各担当者が判子欄にサインして承認するというフローをやっていた。
だから、バグが1日10件も出るととても煩雑になり、バグ管理だけでプロジェクトリーダーが忙殺される時も多かった。

TestLink＋Redmineの良い点は、この作業をチケット駆動開発と言うプロセス上で、バグ修正＆検証のワークフローを明示した点にある。
更に、脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－5　バグ修正に対するRedmineチケットの状態遷移図 」に書いたように、Redmineのデフォルトのワークフローではバグ検証の作業管理がやりにくいので、更にカスタマイズした。

これが本来のバグ修正なのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた時の一つ。

【2】TestLinkのテストケースのステータスには「成功」「失敗」「未実施」以外に「ブロック」がある。
「ブロック」は事前条件を満足できないためテスト不能な状態を表す。
このブロックを初めて使いこなせて、テストにはバグ検証の限界があるのだと気付いた時が、TestLinkによるテスト戦略を感じた2番目の瞬間。

実際にテストしてみると、1個のテストケースが失敗すると、1個のバグが出て、後続のテストケースは全てブロックになる。
更に、バグに依存する機能のテストケースは、全て「みなしバグ」になり「失敗」になる。
また、バグの原因を追求すると、類似バグが出てくる為、更にバグが増えてくる。

ブロックやみなしバグの発生源は、ブロッキングバグと言われる。
まさに、テストどころか開発そのものをブロックしてしまう危険バグを指す。
テスト工程では、ブロッキングバグをいかに早く的確に潰すか、が鍵を握る。

実際は、1個のテストケースの失敗の影響はとても大きく、最低10個のテストケースが「失敗」又は「ブロック」になる時が多い。
つまり、「みなしバグ」や「ブロック」のテストケースはテストしても無意味なのだ。
以前は、「みなしバグ」や「ブロック」の発想がなく、とにかくテストしまくるものの、バグが出た為に再テストするテストケースが多発して、うまく制御できなかった。
だから、無駄にテスト工数を浪費して、肝心のバグ修正がおろそかになる場合も多かった。

そんな経験を経て、イテレーション単位にTestLinkのテスト計画を実施しながら、常にテストの失敗率に注目するようになった。
理由は、テストケースの失敗率がある上限を超えると、殆どのテストケースがブロック又はみなしバグで失敗の状態になってしまい、もはやテストしても無意味になる状態があるからだ。
僕の経験では、失敗率が10％を超えるともはやテストしても無意味で、ブロッキングバグを修正するよりも、最初から単体テストをやり直す方が早いように感じてしまう。

【3】TestLinkのテスト結果はビルドという概念で管理される。
ビルドはビルド番号を指すと教えてもらった時、ビルドでイテレーションを管理すればいいのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた3番目の瞬間。

ビルドの利点は、同じテストケースを回帰テストで管理しやすくなる事。
また、ビルドのテストケースが全て完了したら、ビルド番号を振り直せば、ビルドモジュールの履歴に書かれたチケットNoからバグチケットを探す事ができる。

アジャイル開発にTestLinkを組み込む場合は、TestLinkのテスト計画をイテレーションと見なして、反復型テストを行えばいい。
すると、テストケースを作ってテスト計画を立てた時点で、テスト期間が短すぎたり、テスターや開発者が少なすぎたり、テストケースがそもそも多すぎる場合、実は納期までにテストが終わらない事実が判明する時がある。
原因は、テストと言うスコープを制御できていないのだ。

2～4週間のイテレーションにテスト計画を押し込めるには、2種類の戦略がある。
一つは、イテレーション内で開発とテストの両方を行い、テスト完了後にリリースするインクリメンタル型開発。
もう一つは、開発のイテレーションが完了後、せいぜい数百の単位でテストケースを分割したイテレーションを順次テストしていく反復型テスト。

普通のシステム開発では数千～数万のテストケースに膨れ上がる為、おそらく反復型テストが基本戦略になるだろう。
イテレーションとテスト計画を同一視することで、テストのスコープを制御しやすくしているのだ。

更に、後追いテストや五月雨式テストというテスト戦略も出てくる。
後追いテストは、テスト完了後からリリース直前までに優先度が低いテストケースや未実施のテストケースを後を応用に実施する事。
五月雨式テストは、仕様追加が頻繁な場合、仕様が決まって開発が終了次第、すぐにテストして、五月雨式に開発＆テストしていく事。

後追いテストも五月雨式テストも、十分すぎる品質よりもスケジュールを重視する昨今のビジネスを反映していると言える。
ほどほどの品質をまずは確保した後で、リリースを優先し、品質を作りこむテスト戦略。

プロジェクトリーダーは、インクリメンタル型開発・反復型テスト・後追いテスト・五月雨式テスト等のテスト戦略を意識的に使い分ければ、SW開発で最も難しいテスト工程をコントロールしやすくなるだろう。