TestLinkをユーザ企業が使う時の注意点

下記の記事を読んで、TestLinkは本来、ユーザ企業が発注した業務システムを、ユーザ企業自身が受入テストで使うべきだと思った。
以下メモ書き。

【元ネタ】
TestLink を使ってみた - hokorobiの日記

TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

僕は、TestLinkをテスト工程のうち、結合～システムテストで運用している。
実際は、単体テスト完了したモジュールをリリースする前に、開発部隊が自分たちで業務シナリオベースのテストケースを作り、それでもってテストしている。
つまり、リリース前の品質保持のためにTestLinkを使っている。

でも本来は、ユーザ企業自身がTestLinkを使って、発注した業務システムを受入テストで使うべきなのだ。
理由は、ユーザ企業も受入テストというテスト工程を自身が関与しなければ、システム開発は終了しないこと。
更に、TestLinkは単体テストよりも受入テストの方が威力を発揮するから。

上記の記事で面白いと思ったのは、ユーザ企業自身が受入テストでTestLinkを使った運用例が紹介されていること。
類推すると、下記の運用と思われる。

1.テストケースは、結合テストの観点も入れた業務シナリオベースで作る。
2.テストケース数は 500 強。
3.テスト計画は１個だけ。つまり、全テストケース500個余りがアサインされている。
4.リリースモジュールがβ１、β２、β３、最終Verと渡されるたびに、ビルドを作る。
5.1回通すのが精一杯で回帰テストまでできていない。
6.どのリリースモジュール(つまりビルドに付与されたビルド番号)で、どのテスト(つまりテスト計画)を実行して、どのリリースで修正を確認した(つまりビルド)かが分かりやすかった。

使い方はすごく上手だと思う。
特に、受入テストのテスト計画1個に対し、リリースされるモジュールのバージョンごとにテスト結果(つまりビルド)を残しているので、ビルドが増えるたびに普通はバグの数も減っていくはず。

TestLinkでは、ビルド単位のテスト結果も集計してくれるので、リアルタイムにテスト進捗を把握できる。

僕としては、他の人がTestLinkを運用して、全テストケースに対するテストケースの失敗率を知りたいと思っている。

僕のわずかな経験では、失敗率が5%以上ならば、品質が悪く、リリース後にたくさんの障害修正が寄せられてくる。

例えば、テスト計画のテストケース数が500個と仮定しても、失敗率が5％ならば25件も失敗してバグも25件出たことになる。
受入テストで判明したバグは、単体テストのバグとはレベルが異なり、仕様漏れや要件漏れの原因が多いから、修正工数と再テスト工数が非常にかかる。

又、テストケースには依存関係があるため、1個のテストに失敗すると、10個ぐらいのテストケースも「ブロック」になってしまう。

例えば、Amazonのような小売系Webシステムで、クレジットカード決済の確認画面でテストに失敗したら、クレジットカード決済の受注や受注保守画面で受注データ修正、会計システムへ受注データをバッチ処理、などのテストケースは全て「ブロック」になってしまう。

すると、25ケースも失敗すると、単純に数えると250ケースは「ブロック」になってしまい、全テストケースの半分近くはテスト保留になってしまう。

だから、バグ管理やテスト管理をうまく制御しないと、テストそのものが終わらなくなる。
実際のテスト管理では、ブロックした「みなしバグ」のテストケースは無視して、バグと関係しないテストを先にやったり、本来のバグが修正されたらすぐに再テストを開始するなどの運用が重要になってくる。

TestLinkでは、テスト結果だけでなく、失敗したテストケース一覧やバグ一覧の画面もあるので、テストケースやバグのステータスをリアルタイムに確認できる。

そして、そのテスト結果をTestLinkCnvMacroで分析すれば、各種のメトリクスから色んな気付きが得られるだろう。
テスト実績の累積数のグラフは、信頼度成長曲線とある程度似通ってくるはずなので、品質の判定にも使えるはず。

TestLinkCnvMacroダウンロード - TestLinkTools - SourceForge.JP

僕としては、SRATSを使って最終的には、ソフトウェアシステムのMTBR、MTBFまで自動計算させたい。
そうすれば、リリース判定、出荷判定にも使えるはずだ。

SRATS:Software Reliability Assessment Tool on Spreadsheet Software

その意味では、TestLinkに溜まったテスト実績は、プロセス改善の宝庫とも言える。

TestLinkによるテスト管理には、まだまだ色んな可能性があると思う。