Personal tools
You are here: Home ブログ 井上 ソフトウェア品質のジレンマ
« August 2008 »
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 comments
Re:Software Design 2008年2月号「Emacsマスターへの道」の原稿を公開 elim 2008-07-25
Re:Rails(ActiveRecord)のJOINのイディオム inoue 2008-06-20
Re:「ピアレビュー」を読みました Anonymous User 2008-05-12
Re:「ピアレビュー」を読みました inoue 2008-05-10
Re:「ピアレビュー」を読みました Anonymous User 2008-05-09
Re:「ピープルウェア」再読 inoue 2008-04-20
Re:僅か30分で3つのバグ - Rubyの落し穴 - inoue 2008-04-20
Re:僅か30分で3つのバグ - Rubyの落し穴 - rubikitch 2008-04-19
Re:ソフトウェアインスペクションの試行 horii 2008-03-31
Re:「ピープルウェア」再読 anaka 2008-03-31
Re:WEB+DB Press Vol.43の記事への指摘 yanagisawa 2008-03-25
Re:マルスケと月刊I/O あなか 2008-03-23
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.