アカウント名:
パスワード:
品質目標でのテスト消化項目数が足りないので確認項目を細分化して項目数水増しするとかは不正に入るのだろうか。＃後ろのほうの工程で想定以上のバグが出ちゃって、修正1行なのに品質規定で消化しないといけない項目数が千項目、みたいな悲劇があったりするとどうしてもこうなる
バグ密度が低すぎて水増しした記憶なら…1000ステップ辺り10〜20バグなんてどうやって出すんだよ。
「経験的に平均として出る数値」のはずなのにいつの間にか「目標とする数値」になっちゃうんですよね…
コードを書く経験も乏しく本だけ読んで、こんなものでQAとか言っちゃう連中は悔い改めよ、と言いたい
うちは単体テスト以前の段階、パーツ単位でこまめにドライバスタブ噛ませてテストする習慣があるからいつもテスト段階で出るバグの数が少ないのよね・・・。「後工程に進めばバグ修正の工数は10倍になる、バグは芽のうちに摘むべし」が社長の持論。仕様バグを早期発見してコーディング途中でも設計に突き返すこともよくある。なんでこんなにバグ少ないんだと言われても、そういうふうに作ってるからとしか言えない。
ただ、個人が勘でバグ取りしてるから、エビデンスなんて残ってない。細かなノウハウのメモ書きはあるし、新人もOJTでベテランに叩きこまれるんだけどきちんとした文書は残らない。パーツ単位でのエビデンスもテスト記録として提出物に入れるなら、工数倍お値段倍ですがよろしいですか？
バグって往々にしてテストしてないところで発生するのでエビデンスって意味あるんかね？エビデンスがあるからって実際に不具合があったら何の免罪符にもならないし。こんなのよりも保証期間５年とか１０年を義務付けとかの方が効果があると思うけど。(但しバグに限る)
製品の品質を上げたいなら、(意味のある)テストケースを増やせばいいわけで、エビデンスはその増やしたテストケースを、テスト実施者が、(さぼらずに)実施したかを保つためなのでは(偽装されたらそれまでですが)？
残業でテストするなって内規は破らざるを得ないんです……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
水増しとかありそう (スコア:1)
品質目標でのテスト消化項目数が足りないので確認項目を細分化して項目数水増しするとかは不正に入るのだろうか。
＃後ろのほうの工程で想定以上のバグが出ちゃって、修正1行なのに品質規定で消化しないといけない項目数が千項目、みたいな悲劇があったりするとどうしてもこうなる
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re: (スコア:0)
バグ密度が低すぎて水増しした記憶なら…
1000ステップ辺り10〜20バグなんてどうやって出すんだよ。
Re: (スコア:0)
「経験的に平均として出る数値」のはずなのにいつの間にか「目標とする数値」になっちゃうんですよね…
コードを書く経験も乏しく本だけ読んで、こんなものでQAとか言っちゃう連中は悔い改めよ、と言いたい
Re: (スコア:0)
うちは単体テスト以前の段階、パーツ単位でこまめにドライバスタブ噛ませてテストする習慣があるから
いつもテスト段階で出るバグの数が少ないのよね・・・。
「後工程に進めばバグ修正の工数は10倍になる、バグは芽のうちに摘むべし」が社長の持論。
仕様バグを早期発見してコーディング途中でも設計に突き返すこともよくある。
なんでこんなにバグ少ないんだと言われても、そういうふうに作ってるからとしか言えない。
ただ、個人が勘でバグ取りしてるから、エビデンスなんて残ってない。
細かなノウハウのメモ書きはあるし、新人もOJTでベテランに叩きこまれるんだけど
きちんとした文書は残らない。
パーツ単位でのエビデンスもテスト記録として提出物に入れるなら、
工数倍お値段倍ですがよろしいですか？
Re:水増しとかありそう (スコア:1)
バグって往々にしてテストしてないところで発生するのでエビデンスって意味あるんかね？
エビデンスがあるからって実際に不具合があったら何の免罪符にもならないし。
こんなのよりも保証期間５年とか１０年を義務付けとかの方が効果があると思うけど。
(但しバグに限る)
製品の品質ではなくテストの品質を保つためのエビデンス (スコア:0)
製品の品質を上げたいなら、(意味のある)テストケースを増やせばいいわけで、
エビデンスはその増やしたテストケースを、テスト実施者が、(さぼらずに)実施したか
を保つためなのでは(偽装されたらそれまでですが)？
Re: (スコア:0)
残業でテストするなって内規は破らざるを得ないんです……