アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
手段はともかく (スコア:1, 興味深い)
・前もって見積もったバグの量と比較するため?
・バグの再発を防ぐため?
・バグを作った原因をさぐるため?
・バグを上司に報告させるため?
・バグを直す
Re:手段はともかく (スコア:1, 参考になる)
「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
経験したことが有ります。
ええ。勿論、まともなバグ報告なんて行なえなくなりました。
実際に見つかった数をどうやってそれ以上増やせってんだか。
どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
仕様書に「厳密に従う」方法が最初から存在しない…
Re:手段はともかく (スコア:2, 参考になる)
>バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
>経験したことが有ります。
>ええ。勿論、まともなバグ報告なんて行なえなくなりました。
>実際に見つかった数をどうやってそれ以上増やせってんだか。
コード行数あたりのバグ件数が、経験を元に算出した予想値より極端に小さければ、テスト不十分の可能性が有るので、品質向上と称して再テスト。
予想値より極端に多ければ、ソースの品質が、元からダメダメだったと判断して、やっぱり、品質向上と称して再テスト、と言うようなプロジェクトには、関わった覚えが何度か有ります。
元々は、それなりに合理的な理由が有ったやり方が、いつの間にか形骸化してしまうのは、良く有る事なんでしょうかねぇ。
Re:手段はともかく (スコア:1)
たしか、ピッタリ同じ値でなければ了承してくれなかった、と記憶してます。うわー。
あと、数なんていう細かい点まで拘る割には、「何をどうやって」テストしろ、という指令は、くれなかったなあ。
不十分というからにはテストの「質」を変えないとならない筈だと思いますが、その点についてはノーコメントでした。
新たな観点を授けて(笑)くれて、それでもって見直せば、なるほど数がこう変化するのか!…というのが有るならば
まだ判るんですが、そういうのが何もない。
テストの内容を問わず単に「数が合わないから駄目」と言ってくるだけ。
逆に数さえ合ってれば(テストの内容に突っ込みもせず)OKを出す。
管理してたのは「品質」ではないのでしょうね。
#段ボールいっぱいの仕様書を寄越し、段ボールいっぱいの納品物を納めた(ソースを紙にPrintしないと駄目だったのね)のが、この案件だったと記憶してるのでG7
#仕様書が長いのは、機能が多いからじゃなく、文体からしてワケワカなために異様に冗長になってしまっていたせいです…
Re:手段はともかく (スコア:0)
> いつの間にか形骸化してしまうのは、良く有る事なんでしょうかねぇ。
バグ数だけで見ているからそういう結果を招くのではないかな?
まあ詳しくは書いてないから憶測の域を出ませんが、
バグの収束傾向をも合
Re:手段はともかく (スコア:0)
しかし、あくまでも母集団の統計的な指標で有意を判断するので、特異な(有能な)個人が多い(希な)Prjですと、全然バグ数が少なく、品質保証の担当部署から突っ込みが入ります。
Re:手段はともかく (スコア:0)
・ソースコード上で文字をビットパターンに置き換え、修正前後で異なるビット数をカウントする。
・AかつB、という条件の場合に、Aが3通り、Bが4通りの場合に、その組み合わせを別々にカウントする。
・AかつBの時に発生するのを、AかつBかつCという条件にし、Cが複数のパターンを持たせて、Cのパターン分、水増しする。
・コメント行の誤記もカウントする。
・変数名の英単語のスペルミス