アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
あらかじめ (スコア:0)
Re:あらかじめ (スコア:4, 興味深い)
テスト項目が不足してるとかでもないのに現実に発生していたバグはその1/100足らず。それもそのはず設計段階から徹底的にバグを出さないシステム構築を心がけていましたし、その成果からか出ていたバグもごく一部を除けばコーディング中の単純ミスなどのありがちな原因によるものばかり。しかし客先は必ずこれだけの数のバグ票を出せ、出さないと納品を受け付けないとの一点張り。やむを得ずドキュメントの誤字や、本来はバグではない見栄えの調整などまでバグとして盛り込んで無理矢理件数を増やしました…。
#というか、それまで業務依頼していたソフト会社がバグ出し過ぎなのではないかと…。
Re:あらかじめ (スコア:2, 興味深い)
バグ数が少ないと、テストがぬるい可能性があるとされているので、その関係でしょう。
他の方が書かれている2社も重視していますが、それ以外にも外注に出すときはソコを検収項目として重視されている会社はいくつかあったように思います。
ちなみに私も同じような経験があります。
数年前のことですが、まじめにtest first、dailyインテグレーションをし、週に一回納入先の運用担当者に操作してもらいながら開発した結果、bug数がほぼ1%未満の状態が続く表ができてしまった…なんて思い出があります。いや、やはり納入時に苦労しました。
とはいえ、感想はというとバグに対しては厳しい姿勢で取り組んでいるのだなというもので、理不尽さはなかったのですが…。お人よしなのでしょうか…。
# なんとなく身元がバレそうなのでAC
Re:あらかじめ (スコア:2, 興味深い)
収束曲線とかで目標値が決まってるんです。
で、その範囲を外れると追加の報告書がいるもんで面倒なんですよね。
でも、それって統計的なものなのでプロジェクトによっては
当然誤差が出て範囲に納まらないわけです。
私の場合、面倒なので存在しないバグを適当に追加しときましたよ。
いかにありがちなバグを思いつくか競い合ったものです。
「こんなのどう?」「あ~あるある!」みたいな。
ということを言ってる同僚がいました。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:あらかじめ (スコア:1)
H社グループ...だったっけ?
そもそも、バグ出したことないからよくわからん。
バグよりも仕様変更が怖いよ。
Re:あらかじめ (スコア:0)
ここの確からしさが外野にはわからんのでなんともいいようがないんだけど、
>設計段階から徹底的にバグを出さない
業務設計の段階からやってたらある意味、神だな。
#規模にもよるけどね
Re:あらかじめ (スコア:1)
>業務設計の段階からやってたらある意味、神だな。
>#規模にもよるけどね
システムの詳細要件が事前にきちんと決まっていて、それ以上要件が動かないような案件の場合はそんなに難しいことでは無いですよ。
まぁ、コーディングにかける工数の何分の一かくらいの工数を設計に廻してやれば済むだけの話です。
いやなのが、後出しで「ここはこうしてほしかったのにそうなっていないからバグ」とかいう感じで顧客や発注先からいわれて泥沼にはまる場合ですね…
こればっかしは避けようがないので(T_T)
Re:あらかじめ (スコア:1)
50%は設計に
10%は開発に
40%はテストに
割り当てろと教えています。
設計始まったらすぐに紙芝居を作って、客には開発しているふりをします。
Re:あらかじめ (スコア:0)
業務設計がバグってる典型ではないかと。
Re:あらかじめ (スコア:0)
こことは2度と仕事しないと思った。
Re:あらかじめ (スコア:1)
サブモジュール発注される時、発注側のほうが全体を知らないなんてこともありました。
(無意味なコメントですみません。
誤モデレートしてしまったので、キャンセルのためです)