アカウント名:
パスワード:
どこぞの製造業の会社の偉い人が、「ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ」とおっしゃっているそうですが、LHCの件はぜひ知っていただきたいところ。規模がでかくて特注品なら、ハードだろうがソフトだろうが不具合はあるものです。
…って、言い訳したいよう。(;;)
>それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
テストの合否に関係なく「発見され、潰されたバグの数」が規定に達してなければ無条件で突き返す元請けがいるらしいですよ。
バグが全く発見できないソフトウェアは、永久に納品できないってこと？
製作フェーズ直前でプログラマチームが変更になった。ものすごく優秀な連中。結果、彼らが作成したソースコードは静的検査を掛けてもテストツールかましてもエラーがほとんど出ない。ソフトウェア結合テスト段階でもバグの発生が20件程度しかない。明らかに仕様をきちんと纏めあげた上流工程の奴らと実装を確実にこなすプログラマたちのおかげで高品質なソフトウェアが組みあがっている。例外処理も完全に潰しているし、ランダムテストでもびくともしない。すばらしい出来。
問題は会社の品質管理支援ツール。当初の設定ではバグ検出数を700件と想定して、テスト期間3ヶ月を通して収束する形で計画を立てている。コーディングミスや仕様の誤りなどを含んでバグ条件を設定してあるので今回全く当て嵌まらない。困ったツールで、想定バグ件数に達しないとツール上はフェーズが完了できないというとんでもない仕様。結果、会社のPMOをだます為だけに嘘のバグ報告書を大量に作成して、現実のテストフェーズとは別に管理する羽目になった。プロジェクトは納期より早く完了。立上から1週間後からは関係者は交代で長期の休暇に入った。顧客からは感謝状。しかしツール上は計画したとおりのバグと総合テスト後の障害が発生している事になっている。
そんな今後もありえないような事態で誤って受理拒否する確率より、過去の実績を元に算出した「一定比率のバグの存在」を基準に受け取るほうがトータルでの品質向上に繋がるってことでしょ。
あまり敷居を高くすると本当に受理できなくなるから、95%とか99%の納品物を受理できる程度の「最低バグ発見比率」を定めて運用してると思われ。
この基準だけだとバグが見つかるほど受理されやすくなるから、当然「これ以上見つかるようならダメダメでしょ」という累計発見数なども使った受理基準も整備されてるはず。そういう統計的管理を目指してる所なら。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, オフトピック)
どこぞの製造業の会社の偉い人が、「ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ」とおっしゃっているそうですが、LHCの件はぜひ知っていただきたいところ。規模がでかくて特注品なら、ハードだろうがソフトだろうが不具合はあるものです。
…って、言い訳したいよう。(;;)
Re: (スコア:0)
品質チェックのときにうるさく言われるとかあるんですよねー。
自分の作ったものに不具合はないとは言い切れないけど何か変だと思うんですけどね...
# Japanese Gentlemen Stand Up Please!
Re: (スコア:1, すばらしい洞察)
喰わせるテストデータや条件を変えていってバグを出すんだって。
それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
自分でバグしこんでどうするよ。
Re: (スコア:0)
>それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
テストの合否に関係なく「発見され、潰されたバグの数」が規定に達してなければ無条件で突き返す元請けがいるらしいですよ。
Re: (スコア:0)
一度や二度のテストをパスすることじゃない。
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:0)
バグが全く発見できないソフトウェアは、永久に納品できないってこと？
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, 興味深い)
製作フェーズ直前でプログラマチームが変更になった。ものすごく優秀な連中。
結果、彼らが作成したソースコードは静的検査を掛けてもテストツールかましてもエラーがほとんど出ない。
ソフトウェア結合テスト段階でもバグの発生が20件程度しかない。
明らかに仕様をきちんと纏めあげた上流工程の奴らと実装を確実にこなすプログラマたちのおかげで高品質なソフトウェアが組みあがっている。例外処理も完全に潰しているし、ランダムテストでもびくともしない。すばらしい出来。
問題は会社の品質管理支援ツール。
当初の設定ではバグ検出数を700件と想定して、テスト期間3ヶ月を通して収束する形で計画を立てている。
コーディングミスや仕様の誤りなどを含んでバグ条件を設定してあるので今回全く当て嵌まらない。
困ったツールで、想定バグ件数に達しないとツール上はフェーズが完了できないというとんでもない仕様。
結果、会社のPMOをだます為だけに嘘のバグ報告書を大量に作成して、現実のテストフェーズとは別に管理する羽目になった。
プロジェクトは納期より早く完了。立上から1週間後からは関係者は交代で長期の休暇に入った。顧客からは感謝状。
しかしツール上は計画したとおりのバグと総合テスト後の障害が発生している事になっている。
Re: (スコア:0)
下請に甘んじることもなかろうて。
Re: (スコア:0)
そんな今後もありえないような事態で誤って受理拒否する確率より、
過去の実績を元に算出した「一定比率のバグの存在」を基準に
受け取るほうがトータルでの品質向上に繋がるってことでしょ。
あまり敷居を高くすると本当に受理できなくなるから、95%とか
99%の納品物を受理できる程度の「最低バグ発見比率」を定めて
運用してると思われ。
この基準だけだとバグが見つかるほど受理されやすくなるから、
当然「これ以上見つかるようならダメダメでしょ」という累計発見数なども
使った受理基準も整備されてるはず。そういう統計的管理を目指してる所なら。
Re: (スコア:0)
とあるユーザから「バグが少なすぎる」という痛烈なクレームにビックリ。
なんでもそのユーザの検収部門には、規模に応じた数のバグを指摘して改修させるノルマがあるそうで、次もこんなこと(バグがとても見つけにくいレベルで納品)をしたら絶対に検収上げないぞ、仕事ナメんなってネチネチと。しかも報復的に、ウルトラCクラスの嫌がらせとしか思えない内容のバグを指摘してきた。
仕様には書かれていないが根本に関わる部分だったので、それはもう大変なことになりました。
そういうのは社外だけでなく社内からも言われることがあって、社内規則では、
・テスト項目はテスト開始前にすべて作成してレビューを受けること
・類似バグであっても、複数のテスト項目に該当する場合は個別にカウントする(1つにまとめて数えてはいけない)
となっていて、その日のテスト実施項目数にバグ発見数が比例してしまう。
にもかかわらず、日別のバグ発見数の推移をみて収束してないと言われる。