TestLinkのテスト実績からメトリクス出力

TestLinkに溜まったテスト実績を下記ツールで分析してみたら、面白い傾向に色々気付いた。
以下メモ書き。

【EXCEL試験書からのXMLファイル変換マクロ】
v37b_TestLinkCnvMacro.tar.gz　ダウンロード - TestLinkTools - SourceForge.JP

【主な機能】

(中略)

６ テスト結果の統計データのエクスポート
・指定された期間のビルド単位の試験結果の推移をグラフ化できます。
・試験者を指定した試験結果の推移をグラフ化できます。
・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。

７　要件カバレッジのエクスポート
・プロジェクト内の全要件のカバレッジを、EXCELシートに取込めます。
・要件カバレッジは、指定されたビルドの各テストケースでの最後に実施した結果より求めています。
・要件カバレッジは、要件にアサインされているテストケースの「成功」の割合です。

・仕様カバレッジは、要件仕様にアサインされているテストケースの「成功」の割合です。
・全仕様カバレッジは、全要件仕様にアサインされているテストケースの「成功」の割合です。
・これらは、要件仕様ないで重複してアサインされているテストケースを１個としてカバレッジを求めています。

８　要件カバレッジの統計データのエクスポート
・指定された期間のビルド単位の全要件仕様カバレッジの推移をグラフ化できます。
・要件仕様を指定した要件仕様カバレッジの推移をグラフ化できます。

９　時間帯別の試験結果の統計データのエクスポート　
・指定された日のビルド単位の時間帯別の試験結果をグラフ化できます。
・試験者を指定した時間帯別の試験結果をグラフ化できます。

１０　試験結果のピーク時間帯の統計データのエクスポート
・指定された期間のビルド単位の試験結果のピーク時間帯の推移をグラフ化。
・試験者を指定した試験結果のピーク時間帯の推移をグラフ化できます。

１１　曜日別の試験結果の統計データのエクスポート
・指定日または、指定期間のビルド単位の曜日別の試験結果をグラフ化できます。
・試験者を指定した曜日別の試験結果をグラフ化できます。

１２　時間当り実施数の統計データのエクスポート
・指定期間のビルド単位の時間当り実施数の推移をグラフ化できます。
・試験者を指定した時間当り実施数の推移をグラフ化できます。

１３　試験者別時間当り実施数データのエクスポート
・指定期間のビルド単位の試験者別時間当り実施数をグラフ化できます。
・指定した試験者の指定期間の時間当り実施数をグラフ化できます。

【感想】
【1】上記と似たものとして、SVNリポジトリから、コミット日単位でLOCを表示したり、開発者ごとに曜日・日時単位のコミット数などをHTML出力する下記ツール「statSVN」がある。
＃同様に、CVSリポジトリ統計出力するstatCVSもある。

StatSVN - Repository Statistics - Introduction

僕が重宝するのは、開発者ごとに曜日・日時単位のコミット数などを出力する下記の画面。

StatSVN - Repository Statistics - StatSVN Developers

上記ツールをクーロンで定時にHTML出力する運用をした所、下記の特徴があるという経験をした。

１・駄目なプロジェクト、生産性の低い開発者
・18時以降にコミット回数が多い。
　最悪なのは、夜中1時以降にコミットしている。
　つまり、低い生産性を残業でカバーしようとしている。
・コミット回数の山が金曜や土曜、日曜に来る。
　進捗の遅れを休日出勤でカバーしているから。

２・生産性の高いプロジェクト、開発者
・18時以降のコミットは殆ど無い。
・11時、17時にコミット回数の山が来る。
　おそらく昼前、退社前にコミットするから。
・コミット回数の山が水曜に来る。
　そうしないと、金曜までに作業が終わらない。
　休日出勤しないので、当然、土日はゼロ。

テスト工程も同様の特徴があるだろうと思う。
特に結合テストやシステムテストは元々、コストやスケジュールに余裕が無いので、１のパターンになりやすいと思う。

【2】時間帯別の試験結果グラフを見ると、品質があまり良くなかったテスト計画(イテレーション)では、納期前ほど18時以降にテストが多く、更に全般的に、18時以降のテストは失敗数が多い傾向があった。

又、曜日別の試験結果グラフを見ると、品質が良いテスト計画(イテレーション)では、火曜や水曜など週の前半に山が来る傾向があった。

理由を類推すると、テストケースをどんどん消化できる場合はそもそも18時以降まで残業してテストする必要はない。
テストが遅れると18時以降まで残業し、そこでバグを見つけてしまい、バタバタしてしまうから。
更に、バグを潰していっても、最後の一つのバグが納期直前までなかなか直せない場合が多かった。

逆に、テストケースを順調に消化できる場合は、午前中などで早めにバグを見つけて、18時までに解決しているパターンが多かった。
テスト進捗が順調だから、残業してまでテストする必要はない。

【3】statSVNでSVNリポジトリのコミットする時間帯・曜日別をいつも見る理由は、開発者やテスターの作業負荷を見たいから。

作業負荷が高まると、18時以降に残業してカバーするようになり、休日出勤でカバーするようになり、どんどん状況は悪化していく。

生産性の低さを残業や休日出勤でカバーしようとすると、月曜や火曜のような週の初めや、午前中などの早い勤務時間の生産性がすごく低くなる。
金曜の夜に進捗の遅れがあっても、土日でカバーすればいいや、という学生症候群が生まれてしまう。

そうなるまでに、現場リーダーとしては、対策を考えて手を打ちたい。
上記の資料があると、会社の上層部にも現状を説明しやすくなる。

【4】TestLinkのテスト計画をアジャイル開発のイテレーション単位に対応付ければ、イテレーションをこなすたびにテスト実績がたまっていく。
過去のテスト計画にあるテスト実績を上記マクロで、データマイニングして、メトリクス出力するのは非常に興味深く、又色んな気付きが得られる。

これは、Redmineによるチケット駆動開発でも同様。
ExcelではなくDBにあれば、好きなようにデータを集計して、色んな観点で、プロジェクトを分析できる。

TestLinkでテスト実績をためながら、上記マクロで出力したメトリクスをメンバー全員でKPTでふりかえり、プロセス改善できれば、強力だろう。

アジャイル開発とRedmine、TestLinkは非常に相性がいいと思う。