ゴンペルツ曲線とかそのへんの

バグの消化曲線というよくあるやつの話です。うちの会社のもともとの標準の場合はx軸に工数、y軸に消化件数を取って、これが飽和するようになるはずだ、という方法で品質の安定を見る方法です。

試験の中期ごろにはバグがたくさん出るはずだ
試験もケツのほうになってバグがオラオラ出るのはおかしいんじゃねーか

という考えが根底にありますが、いくつか欠点も指摘されています

試験の実施順序に強く依存するのではないか
x軸の取り方がノンリニアで、品質観点がゆがめられているのではないか

まあ、諸説ありますし、というかどいつもこいつも的を射てます。試験項目の単純網羅性に限っていえば、試験項目も後のほうになるとバグがだんだん出なくなるというのは頷けますが、試験の粒度や試験対象の独立性によっては当然ケツのほうに病巣部の試験を実施することになっていきなりバグ摘出が爆発することもありますし、反対論もごもっともですね。
で、うちの会社の話に戻すと、x軸に工数を取る(別にこのさい「期間」を横軸にとる標準のケースも含めちゃってかまわないです)ような方法だと、試験の実施難易度/手順複雑性に依存してグラフは横に長くなります。んで、この難易度みたいなものと試験対象の品質とはあんまり関係がないはずです。複雑な試験からはたくさんのバグが効率よく摘出されるというわけではないですから。このへんは上に書いた反対指摘の後者のほうの話ですが、加えて最近先輩が言っていたのが『工数を横にとるような方法だと自動テストを導入した場合どうなるんかいな、うちの会社』というもの。なるほどー。工数ってなんの工数なんでしょうね。テストケースの実装工数?それってますます離れた話ですからね。

まあ横軸になにをとるべきか、とかそもそもそういう飽和曲線ってどうなの、というのはおいておいて、そういう品質標準の会社もある上で、いろいろと考えていかねば。またちょっとしたワーキングテーマを発見しました。

# 「こうすればバッチリじゃん」というのは大抵ハードランディングで、いわゆる導入障壁が高かったりして現実的じゃないんでこのへんも難しいんだよなー