スポンサードリンク

かなりマニアックな内容ですが、昔トライして挫折したものだったのと、redmineエバンジェリストの会メンバーが話すので参加

信頼度成長曲線について

信頼度成長曲線は最終障害累積数を予測するもの

定義はいくつかある
横軸は工数だったりテスト数だったり
不具合発生頻度、数が減ってくる前提のグラフ

傾向によって使うものが変わる
ゴンペルツ曲線
ロジスティック曲線
シグモイド

使い方

前提

単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している
→すでにここで無理がある？

機能テストはある程度の欠陥を検出する
性能テストは欠陥はあまりでない
不具合は互いに独立
妥当な曲線になるには６０％のデータが必要
テストの網羅性
テストケースは全て異なる
仕様変更の取り込みはない
テスト終盤では改修されているので減ってくる
→なかなか難しい前提条件

導入への壁

・テストに偏りがある
テストタイプごとにテストを実施する場合

・テストの目的が不具合検出でない場合
チェックのテスト項目を入れる？

・テストの特徴と信頼度成長曲線の性質があわない
残存バグはゼロにならない

・描くタイミング
６割終わったあたりからがよい

・回帰テストを含めるか
入れないのが正しいはずだが入れてるところが多い

・テストの実態と組織標準の曲線が異なる
不具合を早くだす
最初にバグがでるのは嫌
適したグラフを使うのがよい

・横軸に何をとるか
日付、工数、テストケース数、実績

・派生テスト、寄り道テスト、追加テストの扱い

・意図的な歪曲に対する防止策

前提を書かないことが多いからバトルになる #語る夕べ

— 門屋浩文＠redmineエバンジェリストの会主宰 (@MadoWindahead) March 28, 2018

ある程度の長い時間で、、、というところで今の組織では合わないのだけど、前提条件は理解できた

そろうプロジェクト少ないだろうなあ