バグがない・・・本来、それが普通なの？

先日まで、中国人プログラマーが翻訳不足の設計書を閲覧して組んだ成果物の評価業務に従事していました。
バグが酷く、全体の３割程度しか、完成してない有様でした。
最近、日本人プログラマーがとりあえず作った成果物の動作確認に従事しています。が、ここで素朴な疑問が・・・基本的にバグが全く、見当たらないのです。

評価業務って、本来はこんなに、平和な実務なんでしょうか？
強いて見積もっても、97.7％の完成率なので、バグを探すの困難な状態です。ものはHTMLです。HTMLのブラックテストって、どうやってすれば良いのでしょうか？
基本動作確認の他に、何か必須な確認事項は有りますか？
又、参考文献は発売されているのでしょうか？
ちなみにwinソフトのブラックテストの文献は、日経BPから発売されてる様なのですが・・・

97.7％の完成率なので、操作改善程度しか、報告出来るものがないのですが・・・
数値の整合性などは、プログラマ本人に仕様を確認した上で、ざっとチェックしておけば、良いのでしょうか？

No.4 ベストアンサー 回答者： choconamacream 回答日時： 2007/08/07 22:55

Web系ということで。

ペネトレーションテスト入門
http://www.sbcr.jp/books/products/detail.asp?sku …

上記の本では、システムテストとの違いを以下のように述べられております。

システムテスト
→仕様通りの正常な動作となっているか？

ペネトレーションテスト
→攻撃側からの視点でチェック。


あと、私の今の職場での事なんですが、たま～にバグレポートの追加コメント欄で、全く同じのを２度も送信されておられる方がいるんですよ。思うに、その方が使っているマウスが壊れているのか、もしくは本人としてはシングルクリックしたつもりが実際にはトリプルクリックになっているんじゃないかな～と。

本人としては、全く気付いていないのかもしれませんが、こういったこともまた、品質や信頼性を考慮した上ではとても重要なことだと思います。（まあ、開発者さんからしたら、そんなこと誰もしないよって言われそうですが・・。）

この回答へのお礼

ありがとうございます！！お給料出たら、買いに行きます！！
私は操作ミスが少ない性質なので、ミスタッチした想定を全く考慮していませんでした。本当に本の紹介、ありがとうございました。

お礼日時：2007/08/08 23:15

No.3 回答者： lv4u 回答日時： 2007/08/05 23:38

>>先日まで、中国人プログラマーが翻訳不足の設計書を閲覧して組んだ成果物の評価業務に従事していました。

バグが酷く、全体の３割程度しか、完成してない有様でした。

日本と中国では、プログラマの考え方が違います。あちらでは、「求められたもの」を作りますが、「あうんの呼吸」とか「これは常識でしょう？」なんて通用しません。また、コーダは、「品質は私の責任じゃないよ。次の人の責任ね」って発想もあるようです。つまりは分業体制ですね。このあたりを見誤るとオフショアで安く上げたつもりが、逆に高いものになります。

たぶん、日本人プログラマの成果物評価と中国人プログラマの成果物評価は、基準を変えないといけないのではないでしょうか？（質問の回答になってないかもしれない・・・）

この回答へのお礼

個人的な意見ですが、日本人は成果物に対する実務経験がないくせに、担当したがるエンジニアさんが多い・・・身の丈を弁えてないというか・・・国民性なんですかね？
回答ありがとうございました。

お礼日時：2007/08/10 23:55

No.2 回答者： MrBan 回答日時： 2007/08/05 12:11

ANo.1さんのご意見には賛同。

稀にしか見つからない/見つけられない、でも重大なバグを見つけるという
ある種「砂金さらい」のような作業は「平和な実務」なのか、
集中力/注意力の維持だけでも工夫が必要でしょうし、個人的には疑問です。

98%で単純に安心されてしまうようだと評価担当を置く意味がないです。
つまり、質問者さんの業務上の存在意義が消えます。

品質は、ちゃんと意識していれば、開発時点でも80%～90%くらいには
比較的簡単に持っていけます。
そこから99%、ひいては100%に持っていくには、それなりのコストがかかります。
(プログラムに限らずですが、最後の仕上げになればなるほど効率は悪くなります)

工程にもよりますが、ブラックボックスな総合評価段階に入っていると考えると、
完成度90%くらいは普通にあっておかしくありません。(というかそうあるべきです)
98%はそれなりにいい成績だと思いますので、開発陣はマトモなプログラマなのでしょう。

マトモなプログラマ(優秀な職人)は習慣でよいコードを書きますから、
たとえ「とりあえずの成果物」でも、単純なものなら些細なミスなどはそうそうありません。

> 数値の整合性などは、プログラマ本人に仕様を確認した上で、
> ざっとチェックしておけば、良いのでしょうか？

ブラックボックステストである以上、仕様の確認は、プログラマではなく、
設計者に対して行うべきです。

まぁ設計者=プログラマの兼任なのかもしれませんが…だとすると、
少なくとも設計と実装での意識ズレは起きませんから(考えた人と書く人が同一)、
結果として検出されるバグ(仕様バグ)も減って当然でしょう。
顧客要件と設計が合致しているか、という問題はありますが、
そこに責任を持つか/口を出すべきか否かは質問者さんの立場によります。

この回答への補足

ご本人は謙遜して（派遣SEなので）実用される可能性を低く考えておられるのですが、第三者の後輩派遣の私からすると、彼以上の物を作れる方が、他におらん状況です。導入日も迫ってるので。

肝心のボスがHTMLの素地がない方なので、私が仕様を詰めさせてもらうしか、手がないと言いますか・・・
こんなに完成度が高い場合、操作性を細かく追及するのは迷惑だったらどうしよう・・・
とにかく実際のオペレータさんが１～２分で入力が完成する方向で、ガンガン要望出しても良いのでしょうか？
私はオペレータのレベルに合わせて、予算に合わせていくらでも、不便な提案・便利な提案をするのみです。
こんなに無駄が無いコードを見るのは初めてです。
というか、私の前派遣先が、そうとうヤバかっただけの気がします・・・

補足日時：2007/08/05 13:11

この回答へのお礼

おっさんが「余計な口出しするな！！」とおっさる以上、
私もプロさんも、何も言えないですよね・・・状態です。
ホントは全て、自動処理化に出来るものを、あえてアナログに作る意味も分からない・・・おっさん謎・・・
私はどうも、おっさんの話相手として、採用された様です。
砂金探し派として、頭を切り替えてがんばります。
回答ありがとうございました。

お礼日時：2007/08/10 23:46

No.1 回答者： don_go 回答日時： 2007/08/05 10:42

１つの計算ミス、条件判断ミスが、多大な損失を

与える事もあるのですから、97.7%の完成率だから
と安心してはいけません。
むしろ、そういった時のほうがエラー箇所を見逃し
やすくなるので油断は禁物です。

評価業務というのは、客先に対して不具合の残る
製品を出さない為の最後の砦です。

この回答へのお礼

本日無事、基本動作の確認を報告しました。
自称SEなおっさん（社員）が最終デザインを出さずに夏休みを取りやがったため、肝心な手打ち画面の検証が出来なーい！！オーマイガーッ！！何でおっさんは、毎日違う事を言い、日々うそをつくのでしょう・・・謎。
なんで会社って、仕事が出来ない人を解雇しないのでしょうか？
回答ありがとうございました。

お礼日時：2007/08/10 23:39