Personal tools
You are here: Home ブログ 井上 ソフトウェア品質のジレンマ
« December 2010 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Recent entries
Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23
Herokuの発音 inoue 2010-12-20
雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18
IPA未踏のニュース inoue 2010-12-15
労基法とチキンゲーム inoue 2010-12-06
フロントエンドエンジニア inoue 2010-12-03
ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25
技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24
雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22
RESTの当惑 inoue 2010-11-22
「プログラマのためのUXチートシート」を作りました inoue 2010-11-19
「ビューティフルコード」を読みました inoue 2010-11-16
Categories
カテゴリなし
 
Document Actions

ソフトウェア品質のジレンマ

以前、「バグがでないのは良い知らせなのか」という記事(http://dev.ariel-networks.com/Members/inoue/bug-and-test)で、横軸に時間、縦軸にバグの報告件数を取ってバグの収束を見ることへの疑念を書きました。

同じ問題意識を持っている発表資料を見つけました。

横軸が経過時間では良くない、という主張です。その代わりとして、テスト項目数(実施数)を横軸に書く案を挙げています。

この辺の数値はそれなりに記録しています。グラフにするのも(gnuplotとシェルを使えば)簡単です。問題はグラフの解釈です。これが実に難しい。どれぐらい難しいかと言うと、もう7年ぐらい考えているのに未だに分からないぐらいです。

テストがまだ充分ではないという判断ができることは多々あります。しかし、人間の疲労度とのトレードオフがあります。もし、10人でテストをして一日で見つかった有効バグが2,3件だとします。ソフトウェアの品質の観点から言えば、一日に有効バグが2,3件も見つかるならまだテストが不十分と判断するかもしれません。しかし、作業する人の立場になってみると、10人のうち、ほとんどの人は有効バグの発見数がゼロだったということです。これが数日続くと実に辛いです。ひどい徒労感に襲われます。最後のソフトウェア開発なら、とことんまでテストするのも手かもしれませんが、今後も開発を継続するつもりなら、適度なところで切り上げる必要があります。人が疲弊して辞めたり意欲を失う損失と、多少のバグを見逃してリリースしてしまう損失を比較するなら、ほとんどの場合、前者の方が損失が大きいからです。

The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/inoue/software-quality-dilemma/tbping
Add comment

You can add a comment by filling out the form below. Plain text formatting.

(Required)
(Required)
(Required)
This helps us prevent automated spamming.
Captcha Image


Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.