アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
手段はともかく (スコア:1, 興味深い)
・前もって見積もったバグの量と比較するため?
・バグの再発を防ぐため?
・バグを作った原因をさぐるため?
・バグを上司に報告させるため?
・バグを直す
Re:手段はともかく (スコア:1, 参考になる)
「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
経験したことが有ります。
ええ。勿論、まともなバグ報告なんて行なえなくなりました。
実際に見つかった数をどうやってそれ以上増やせってんだか。
どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
仕様書に「厳密に従う」方法が最初から存在しない…
Re:手段はともかく (スコア:2, 参考になる)
>バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
>経験したことが有ります。
>ええ。勿論、まともなバグ報告なんて行なえなくなりました。
>実際に見つかった数をどうやってそれ以上増やせってんだか。
コード行数あたりのバグ件数が、経験を元に算出した予想値より極端に小さければ、テスト不
Re:手段はともかく (スコア:0)
> いつの間にか形骸化してしまうのは、良く有る事なんでしょうかねぇ。
バグ数だけで見ているからそういう結果を招くのではないかな?
まあ詳しくは書いてないから憶測の域を出ませんが、
バグの収束傾向をも合わせて検討する統計的な手法は必要でしょう。
収束しないなら問題があるが収束していくなら良いというような。
もっとも、概ね開発とテストチームは別にする必要はありますが。
#容赦ないテストチームが望ましい(w