アジャイル開発でも信頼度成長曲線は有効か？ツールを使って確かめてみよう
ootakenの投稿 (2011年12月2日)
続けてですが、僕も「Software Test & Quality Advent Calendar 2011」の12/2エントリーとして、書きます！
皆さんはテストの完了条件をどのように設定していますか？
多くはテストで発見した障害に対して、重要度もしくは優先度をつけて、
重要度高の残障害 0件
重要度中の残障害 5件
のような条件をクリアーした時に、テスト完了とすることが多いと思います。しかし、これではこれまで発生した障害のみの情報に頼ってテストの完了条件としているため、テスト完了後に発生しうるリスクに対して備えているとは言えません。
それを補完とする手法の一つとして信頼度成長曲線があります。
え、それってメインフレーム時代の大規模プロジェクトとかにしか使えないやつじゃないの？今のアジャイル開発には使ええないよね。俺はTDDで開発しているからバグ出さないぜ、そんなの関係ないよ。
とか言われそうですが、まあ、僕もそう思っていましたが、先ほど障害の重要度や優先度ってそもそも人が付けるものなのでそれ自体主観的でまるで定量的とは言えないので、ちょっとは定量的な根拠がほしいですね。
ということで、最近自分も信頼度成長曲線をなんとか実プロジェクトで使えないかなーと試行錯誤していたのですが・・・そもそもかなり確率統計のバックボーンが必用でかつ自前で一から計算するのはすごく大変だったりします。どの近似曲線を選べばいいのかというのもこれまた経験だけでなく、数学の知識が必要です。
と挫折しかかっていたところ、Excel上で簡単な入力で信頼度成長曲線を描いてくれてかつ、予想総バグ数、予想残存バグ数までを求めてくれるツールを発見しました。
SRATS (Software Reliability Assessment Tool on Spreadsheet Software)
Excelのマクロとして作られています。難し話はさておき、
障害が発見された時間間隔 障害時間
45 1
60 2
のようにテストを開始してから45分後に1件見つかった、その60分後に2件見つかったという風にExcelに記入していき(TracやJIRAのような障害管理ツールからエクスポートすると簡単です)、その時間間隔データを対象にしてSRATSを実行すると、先ほどの予想総バグ数(厳密にいうとバグではなくその結果である障害数)をはじめとする各種の値とグラフが出てきます。
もちろん、あくまでツールは理論に基づいて値を算出しているので、実際のプロジェクトに適用するにはテスト完了基準の一つとしての参考値ぐらいにとどめておくのが無難です。しかし、明らかに障害の発見が収束していない、そのテスト後の障害発生数が高すぎるというリスクを判断する材料には使えます。
注意点として、僕も経験しましたが、通常の障害管理ツールには障害が発見された時間間隔というのは記録されておらず、障害の発見日時もしくは障害票の起票日時のみが記録されていることが多いので、ツールからExcelへエクスポート後、開発の営業時間、テストの実稼働時間を考慮して、障害の発見日時から障害が発見された時間間隔を算出する必要があります。僕はここをマクロで自動化しようと思いましたが、休日出勤とか毎日のテストの実稼働時間とかが異なることまで考慮すると自動化がちょっと困難だったので、エクスポート後手動で算出しています。あんまり多くの障害票がある場合、やはり自動化したほうがよいかもしれません。
で、肝心のアジャイル開発のような短期間開発のスプリントやイテレーションにも使えるのかという話ですが、それは皆さんで試してのお楽しみです。というのも、あまりに乱暴なので、ひそかに障害票からエクスポートして検証してみた感じでは思ったより使えます。特にリリース後に発見された障害まできちんとトラッキングしていくとどれだけ曲線の精度があるのかが経験値としてチームや組織に定着していくようになると思うので、まずはひそかに計測してみるというのをやってみるとよいかなと思います。
