プログラマの思索

信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。

【元ネタ】
Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ！スーパーエンジニア

どこでテストをやめるのか？ 日本電気株式会社 川村真弥さん

オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用

成長曲線（ゴンペルツ曲線とロジスティック曲線）

つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め

テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOist

プログラムバグの成長曲線とプログラム品質の判定

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。
つまり、テストの止め時は、信頼度成長曲線が収束した時なのだ。

すなわち、信頼度成長曲線はリリース判定の基準の一部になるので、とても重要な指標になる。
逆に、システムをリリース判定するのに、単純にテストが終わったから、納期が迫ったからという理由でリリースすれば、納品後に契約違反という名のクレームが顧客から届くことになる。

日本では製造業の品質管理の手法を用いて、ソフトウェアに対しても信頼度成長曲線を応用する手法が多いと思う。
しかし、ソフトウェアの場合、ハードウェアと違って、実際は綺麗な信頼度成長曲線にならない場合が多い。
例えば、いくらテストしても、バグがどんどん出てきて、直せば直すほど品質が不安定になっているプロジェクトも多いだろう。
あるいは、せっかくテストでバグを潰しきっても、次から次へと仕様変更や仕様の追加が届いて、それに対応する度にバグが出ては直す作業の繰り返しばかりで、いつまで経っても品質が安定しないプロジェクトも多いだろう。

だから、信頼度成長曲線はソフトウェアでは使えない、あるいは、ソフトウェアの信頼度成長曲線はバッドノウハウが多い、という話はよく聞く時が多い。

上記の資料を読んで思ったことは、信頼度成長曲線を使いこなすには、いくつかのノウハウが必要だということ。

一つは、時系列にバグ累積数を並べるとき、横軸を時系列ではなくテストケース数やテスト工数を並べた方が良いというアドバイス。
理由は、時系列に並べた場合、テスト終盤ではテストしない日も多いので、当然バグ数は一定になるが、実際にその状況は品質が安定したことを意味していないから。
つまり、テスト工程の品質が担保されている場合、テスト工数やテストケース数を横軸に時系列にバグ累積数を並べれば、叩いた分だけソフトウェアが安定しているかどうか、少なくとも分かる。

もう一つは、スコープを固定すること。
理由は、テスト工程なのに、次から次へとやってくる顧客の要望を受け入れてシステムに機能追加すれば、障害修正と機能追加が混じってしまって、品質はなかなか安定しないから。
デグレも多発するだろう。

アジャイル開発の利点の一つは、イテレーションという期間では、要望やスコープを固定させるため、その期間中はよほどのことがない限り、機能追加しないこと。
スコープの固定によって、テストでバグ出しして障害修正するほど、品質は少なくとも安定してくるはず。

駄目な開発チームは、テスト工程になっても、設計漏れという理由でスコープを固定できないため、いつまで経っても開発し続ける羽目になり、デスマーチに陥る。

いつテストを終わらせるか？という判断はとても難しい。
テストには、単にJUnitのような単体テスト、Seleniumによる結合テストだけでなく、ユーザの観点の受入テストや負荷テスト、セキュリティのテストなどもある。
実際のプロジェクトでは、テストすればするほど、バグが出るのが普通だろう。
テストを終わらせる判定基準に信頼度成長曲線を使う場合、運用ノウハウが必要だ。

だが、そのノウハウはどの企業もなかなか公表しない。
そのノウハウは比較優位の源泉だからだ。
だからいつまで経っても同じような失敗を続けてきて、日本のIT企業のレベルは上がっていないように思う。