テスト手法の概念をTestLinkで説明する

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。

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

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

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

下記の資料にまとめてみた。
ちなみに下記のテスト用語(方言？)はTEF関西のNakaさんから教わった。

Test Linkのテスト手法 from akipii Oga

【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念

上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。
その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、開発者をびびらせる意味も込めて「失敗」にする。
つまり、カート削除2のテストケースは、みなしバグになる。

更に、カート機能でバグが発生していて注文機能のテストを進められない状況の場合、注文機能のテストケースは全てテスト保留にする。
つまり、注文機能のテストケースはブロックになり、カート機能のバグが解消され次第、テストを再開できる。

又、カート削除1のテストケースからRedmineへバグチケットが発行される。
このバグは、みなしバグやブロックしたテストケースなど数多くのテストケースに影響範囲があるから、ブロッキングバグになる。
つまり、ブロッキングバグはテスト進捗を妨げる重大なバグである。

ブロッキングバグの修正が完了し再検証する場合、テスターには、ブロッキングバグの検証だけでなく周辺の関連機能も回帰テストするように管理者は指示しておく。
理由は、ブロッキングバグの修正で、デグレが起きていないか、他機能への考慮漏れが発生していないか、確認して欲しいからだ。
上記の例では、カート投入機能は既に成功しているが、もう一度最初から、カートへ商品を投入してカートから商品を削除するようにテストする。
これを周辺テストと呼ぶ。

Ver2.0のテストを実施していて、今回の機能改修でソースを修正しなかった機能のテストは、既に運用済みで品質が担保されている場合もありうる。
例えば、Ver2.0で念のために実施する必要があるものの、テスト工数や納期の関係で優先順位が低くテストしなくてもいい場合がある。

これらのテストケースをあらかじめ成功にするが、テストを実施して成功にする状態と区別するために、みなしOKというステータスにする。
但し、みなしOKのテストケースでもしバグが発生したら、結局全てのテストケースを再テストする必要がある。

上記をまとめると、テスト実行後のステータスは、未実施・成功・失敗・ブロック・みなしOKの5種類がある。
更に、テスト結果の検証に時間がかかる場合、検証中というステータスも欲しくなるだろう。
例えば、クレジットカードのシステムでリボ払いの計算結果を検証する時、テスト結果を取得するだけで、検証は後日行う場合があるだろう。
この場合では、テスト担当者とテスト検証者は異なる時が多いだろう。
つまり、ステータスは、未実施・成功・失敗・ブロック・みなしOK・検証中の6種類は最低必要ではなかろうか？

TestLinkでは、ステータスが未実施・成功・失敗・ブロックしかなく、GUI上からステータスを増やせない弱点はある。
しかし、Ver1.8以降では、設定ファイルcustom_config.inc.phpに下記の記述があるので、ステータスを増やせるかもしれない。

// $tlCfg->results['status_code'] = array (
// "failed" => 'f',
// "blocked" => 'b',
// "passed" => 'p',
// "not_run" => 'n',
// "not_available" => 'x',
// "unknown" => 'u',
// "all" => 'a'
// );

【2】後追いテスト、五月雨テストの概念

上記2枚目で、Ver1.0のリリースが目前に迫っている時だとしよう。
携帯のような組込み機器、業務システム、パッケージ製品のリリース直前では、1週間前～1ヶ月前からコードがFreezeされて、開発チームは、インストーラを作成したり、本番環境を構築する等のリリース作業に入る。
リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、回帰テストを行うテスト手法を後追いテストと呼ぶ。

後追いテストの目的の一つは、空き時間を使って更なる品質チェックを行うことだ。
普通は、この時期では、製品に重大な支障が発生するようなバグは全て潰されているはずだが、表示がちょっとおかしかったり、UIをもう少し改善できるなど、些細な修正点はテストすればするほど出てくるはずだ。
そのようなプロダクトリスクの低いバグを洗い出し、次のVer1.1へマージしてリリースできるようにする。
但し、後追いテストで重大なバグが見つかった場合は、Ver1.0のリリースを延期することもあるだろう。

Webシステム開発では、リリースした本番ブランチ上のシステムに対して、リリース後に後追いテストで優先順位の低いテストを行う時もあるだろう。

一方、開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
例えば、携帯のテストならば、SNSメール登録が先に開発できて、普通の携帯メール機能は開発中の場合、SNSメール登録を先にテストしてバグ出ししていく。
そのテスト結果を開発チームにフィードバックして、普通の携帯メール機能にも取り込んでいく。

アジャイル開発は基本は五月雨テストだと言える。
つまり、開発できた機能から順次テストしていく開発スタイル。
脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で紹介した僕のテスト手法は、五月雨テストと同じだ。

僕がTestLinkを運用した時、テスト計画のテストケースが少ない場合、テスト計画をイテレーションに含めた。
逆に、テスト計画のテストケースが多い場合、開発のイテレーションから分離して、テスト計画を更に分割して、複数のイテレーションで順次テストしていった。
例えば、結合テストPh1・Ph2、システムテストPh1・Ph2・Ph3のようにテスト計画を順次実施していくテスト戦略になる。

僕のやり方とは別に、第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記にあるhokorobiさんのテスト手法のように、1個のテスト計画で複数のビルドで管理する方法もある。
これは、Excelのテスト仕様書の管理と同じように、1個のテスト仕様書へ結果を追記していくのと同じやり方だ。

僕もこのやり方を試した時はあったが、アジャイル開発に組み込みにくかった。
理由は、イテレーションと言う概念を当てはめにくいから。
テストで一番嫌なのは、テストすればするほどバグが出て、バグ修正＆検証がエンドレスになってしまうこと。
イテレーションがあるからこそ、リリースが定期的にあり、プロセスを改善するタイミングが生まれやすい。

また、ビルドの途中でテストを中断して、次のビルドに移るから、テスト実行結果のステータスが曖昧になりがち。
そもそもブロックを使う必要もない。
ブロックや見なしバグなどが必要な理由は再テスト工数を計算したいからだ。
100件のテストを行う場合、10件失敗すれば、テスト工数は110件も膨れ上がる。
プロジェクト管理の基本はクリティカルパスの管理だから、再テスト工数を見積もるのは非常に重要なのだ。

又、テスターが少なすぎたり、テスト期間が短すぎたり、テストケース数が多すぎると、テスト計画を立てた時点でもはや全てテストできなくなる確率は大きい。
特に、デシジョンテーブルや直交表でテストデータのパターンを作りこむシステムテストでは、テスト網羅の観点からテストケース数が爆発しやすく、その危険は高い。
だから、イテレーションにテスト計画を組み込むことで、テスト工程のマネジメントを管理しやすくするのだ。

【3】とある勉強会で、最近のシステム開発の傾向は品質よりも納期を重視しているようだ、という話があった。

ビジネス的背景としては、3ヵ月後の景気すら誰も分からない状況で、数年もかけてシステム開発するのはリスクが非常に高い。
また、MixiアプリやGoogleのサービスのように、先にリリースした者がマーケットを支配する状況が多くなっているからだ。
だから、最低限の品質は担保した上で、小刻みにリリースしていく開発スタイルが多くなっているように思う。

更に、技術的背景としても、後追いテスト、五月雨テストのようなテスト手法がやりやすくなっている。
例えば、携帯電話やiPodのような組込み機器でも、リリース後にSWアップデート機能でアプリケーションだけでなくROMそのものも更新できるようになった。
Webシステムなら、サーバーにデプロイさえすればいいから、リリースしやすい。

つまり、後追いテスト、五月雨テストのようなテスト手法は昨今のSWテストにマッチしやすい特徴があると思う。

TestLinkはまだまだ機能改善の余地があるけれど、上手に使いこなせれば、テストプロセスの品質向上で大きな威力を発揮できると思う。