2015年5月
          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            
無料ブログはココログ

« 【ソフトウェア信頼度成長モデルを考える④】グラフが寝るとはどういうことか① | トップページ | 【ソフトウェア信頼度成長モデルを少しまじめに考える①】直感的理解容易性のために忘れられがちであるが悩ましい前提① »

2009年3月 6日 (金)

【ソフトウェア信頼度成長モデルを考える⑤】グラフが寝るとはどういうことか②

簡単な仮想事例で考えてみる。
ソフトウェア信頼度成長モデルを用いてテスト十分性を見ようという場合に、新機能確認Aを2000件行った後、新機能確認Bを2000件、レグレッションテストを5000件行ったところ、綺麗に曲線が寝たという場合に喜んで良いのか。

次の3つの順番で行っても、同様に寝るのか。

①新機能確認Bを2000件行った後、新機能確認Aを2000件、レグレッションテストを5000件行う
=>これはまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

②レグレッションテストを5000件行った後,新機能確認Aを2000件、新機能確認Bを2000件行う
=>モデルが想定するような綺麗な形には寝ないだろう。

③新機能確認Aを1000件行った後、新機能確認Bを1000件、レグレッションテストを5000件行う
=>これもまあ、寝方は変わるだろうが寝る可能性が高いのではないか。

ある程度のケース数のレグレッションテストを最後に持ってくれば、新機能確認のケース数の多少に関係無く一般的に曲線は寝ることが多い。

つまり、先ほどの例で言えば、

   ・最初から寝ることが分かっているレグレッションテスト
の前に、
   ・通常寝ない新機能確認A、B

を持ってくれば、実際のソフトウェア内のバグの残存に関わらず「最初から寝る」可能性が非常に高い。
これを以って、「ソフトウェア信頼度」が成長したとか言うのは全くナンセンスである

このようなことは、わざわざ例示までしなくとも、誰にも理解できるであろう。

しかし、頭で理解できてもこれを考慮してテストを実施することは、非常に難しい。
通常、実際のテストにおいては、テストの実施順番は、機能・重要度・リスク等によってグルーピングしており、
    バグがテストケース全体にわたって同じ発生確率でばらまかれていること
という前提が、十分仮定として成り立つようなテストの方が少ないであろう。

ソフトウェア信頼度成長モデルの前提については、別途詳しく考えることとする。

« 【ソフトウェア信頼度成長モデルを考える④】グラフが寝るとはどういうことか① | トップページ | 【ソフトウェア信頼度成長モデルを少しまじめに考える①】直感的理解容易性のために忘れられがちであるが悩ましい前提① »

ソフトウェア開発品質・生産性私見」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1048600/28416694

この記事へのトラックバック一覧です: 【ソフトウェア信頼度成長モデルを考える⑤】グラフが寝るとはどういうことか②:

« 【ソフトウェア信頼度成長モデルを考える④】グラフが寝るとはどういうことか① | トップページ | 【ソフトウェア信頼度成長モデルを少しまじめに考える①】直感的理解容易性のために忘れられがちであるが悩ましい前提① »