1. はありえない。本当にPGなら。 ただし、バグがあると分かっていてリリー..
1. はありえない。本当にPGなら。 ただし、バグがあると分かっていてリリースするアホはこれまたありえない 正解は「プログラマーはバグがあると分かっていて、バグも内密に積み上げられているが、リーダーはバグがないと”信じている”とコメントする」じゃないのかな？ 2. ３０個どころではない気もするが…小規模ならそんなモン？ 単体で確率的に1/5。総合で更に2/5程度で掛け算するといい感じかも 3. １０個のバグを修正し、 １０個は仕様だと答え、 １０個はテストデータに由来するから問題ないと考え、 １０個は再現しないと付き返す 残りの１０個は何が悪いのか判断もできず 余った１０個は自分の作業範疇ではないと考えて放置したまま …キリの悪い数字だな 4. 割合的にデグレ＋デバックで浮上するバグはこんなモンかなー。 5. デバック：テスト１回あたりのスパンが週とか１ヶ月程度だと繰り返す。 （３，４回ど
プログラマの慢心。IT業界の現状。
友人から以下のようなメールが送られてきて、ホントなの？と聞かれた。 1. プログラマがコードを書く。バグはないと信じている。 2. 製品テストが行われて30個のバグが発見される。 3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。 4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。 5. 上記の工程3、4を数回繰り返す。 6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。 7. ユーザにより100個のバグが発見される。 8. プログラマが他社に転職する。 9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。 その過程で新たに500個のバグが生まれる。 10. テストチームの
ITなひとだけ笑えるネタ。
笑えないかも。 わたしの近所のプロジェクトで採用されている、斬新なプログラム開発手法についてご報告いたします。「IST」といいます。ISTとは「いきなりシステムテスト」の略です。どんな感じに進むかと申しますと、 システムテスト行程開始！ 試験担当者がバグ報告票を書きます。 「バグ：アプリケーションのアイコンがありません」 開発担当者が対応します。 「理由：アプリケーションのアイコンを作っていませんでした」 「対処：アプリケーションのアイコンを作りました」 試験担当者がバグ報告票を書きます。 「バグ：アプリケーションのアイコンをクリックしても、なにも起きません」 開発担当者が対応します。 「理由：メイン処理がありませんでした」 「対処：メイン処理をコーディングしました」 試験担当者がバグ報告票を書きます。 「バグ：（再）アプリケーションのアイコンをクリックしても、なにも起きません」 開発担当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
