なぜバグ曲線は収束するのか

Size: px

Start display at page:

Download "なぜバグ曲線は収束するのか"

たかよしやぶき
5 years ago
Views:

1 なぜバグ曲線は収束するのか ~Microsoft Excel を使って考えてみる ~ JaSST 13 Tokyo 2013 年 1 月 31 日丹羽岳雄株式会社日本総合研究所

2 バグ曲線はソフトウェア開発の品質管理ツールの 1 つとして広く活用されている

3 バグ曲線でよく議論されていることより良いモデルの構築? 曲線収束の判定方法? 最適なモデルの選択方法? 横軸は時間? 工数? テストケース数? なにか足りない

4 バグ曲線でよく議論されていることあまり議論されている感じがしないことバグ曲線はなぜ寝るの?

5 本セッションの構成 0. はじめに 1. バグ曲線収束理由の検討 2. 収束理由を踏まえたバグ曲線の活用 3. おわりに

6 バグ曲線収束理由の検討バグ曲線が収束するとは結果論としてバグがテスト期間の始めの方でたくさん見つかっているということならばそれを考えてみよう

7 バグ曲線収束理由の検討検討する収束理由 1 テストケースの成り立ち上必然的に生ずるものある項目をテストしようとすると他の項目もテストしてしまう 2テスト実施者の意図に由来するもの意図の例バグ原因となる箇所を予測したテスト恣意的な実施順の決定

8 テストケースの成り立ち上必然的に生ずるもの TestCaseNo. 確認したい項目 1 い 2 ろ 3 は 4 に 5 ほ 6 へいろはにほへと 7 と 8 A A B C 9 B 10 C

9 テストケースの成り立ち上必然的に生ずるものいろはに A A は No.8 の前に No.1~4 の 4 つのテストケースで事前に確認されてしまう TestCaseNo. 確認したい項目 1 い 2 ろ 3 は 4 に 5 ほ 6 へ 7 と 8 A 9 B 10 C

10 テストケースの成り立ち上必然的に生ずるもの A を確認するための No.8 のテストケース実行前に No.1~4 の 4 つのテストケースで A について事前に確認されてしまう個々のバグを発見できるのはその部分の確認を意図するテストケースだけとは限らない個々のバグを発見できるテストケース数が多ければバグ発見が早くなる ( のでは?)

11 個々のバグを発見できるテストケース数が多ければバグ発見が早くなる ( のでは?) テストケーススイート 1" - テストケース件 - バグ 200 件条件 1 各バグは1つのテストケースのみで発見重複無条件 2 各バグは3つのテストケースで発見 3 件重複条件 3 各バグは5つのテストケースで発見 5 件重複

12 個々のバグを発見できるテストケース数が多ければバグ発見が早くなる ( のでは?) あるバグを発見可能なテストケースが何番目のテストケースで実行されるかは乱数を生じさせるエクセル関数を使い RANDBETWEEN (1,10000) と表すことができる 3 件重複であればバグを最初に発見できるテストケースの実施順は MIN ( RANDBETWEEN (1,10000), RANDBETWEEN (1,10000), RANDBETWEEN (1,10000) ) と表すことができる ( 厳密には 3 つの乱数がそれぞれ異なるような処理が必要 )

13 個々のバグを発見できるテストケース数が多ければバグ発見が早くなる ( のでは?) - テストケース件 - バグ 200 件はそれぞれの関数を 200 回実施して得られる値を昇順に並べて累積的にグラフを描けばバグ曲線が得られる条件 1 各バグは 1 つのテストケースのみで発見重複無 RANDBETWEEN (1,10000) 条件 2 各バグは 3 つのテストケースで発見 3 件重複 MIN ( RANDBETWEEN(1,10000), RANDBETWEEN(1,10000), RANDBETWEEN(1,10000)) 条件 3 各バグは 5 つのテストケースで発見 5 件重複 MIN ( RANDBETWEEN(1,10000), RANDBETWEEN(1,10000), RANDBETWEEN(1,10000), RANDBETWEEN(1,10000), RANDBETWEEN(1,10000))

14 個々のバグを発見できるテストケース数が多ければバグ発見が早くなる条件 1 : 各エラーは 1 つのテストケースのみで発見条件 2 : 各エラーは 3 つのテストケースで発見線形寝てきた? 条件 3 : 各エラーは 5 つのテストケースで発見収束でしょうテストケーススイート内に同一バグを発見できるテストケースが多いほどバグ発見は早くなる

15 テストケースの成り立ち上必然的に生ずるもの三段論法あるテストケースが他の項目もテストしてしまう重複は収束理由になるバグ発見は早くなるバグ曲線は収束しやすくなる

16 バグ曲線収束理由の検討検討する収束理由 1 テストケースの成り立ち上必然的に生ずるものある項目をテストしようとすると他の項目もテストしてしまう 2テスト実施者の意図に由来するもの意図の例バグ原因となる箇所を予測したテスト恣意的な実施順の決定

17 テスト実施者の意図に由来するものバグを早く発見したいというテスト実施者の意図バグ原因となる箇所を予測したテスト恣意的な実施順の決定 etc これらが上手くいけばバグ発見は早くなるバグ曲線収束に貢献!

18 テスト実施者の意図に由来するものでバグ発見が早くなる ( とバグ曲線は収束するのでは?) テストの早い段階ほど発見できるテストケースが多いことは例えば以下のように表すことができるテストケース区間. 発見障害件数 ( 重複無しとする ) 1, , , , RANDBETWEEN (1,2000) が 90 個 RANDBETWEEN (2001,4000) が 40 個 RANDBETWEEN (4001,10000) が 20 個 RANDBETWEEN (6001,10000) が 8 個

19 テスト実施者の意図に由来するものでバグ発見が早くなりバグ曲線は収束に向かう ( かな?) RANDBETWEEN (1,2000) が 90 個 RANDBETWEEN (2001,4000) が 40 個 RANDBETWEEN (4001,10000) が 20 個 RANDBETWEEN (6001,10000) が 8 個まあ収束していく形に見えるように値を選んだのだから自演と言えば自演

20 バグ曲線収束理由の検討検討する収束理由 1 テストケースの成り立ち上必然的に生ずるものある項目をテストしようとすると他の項目もテストしてしまう 2 テスト実施者の意図に由来するもの意図の例バグ原因となる箇所を予測したテスト恣意的な実施順の決定 31 と 2 の複合形

21 テストケースの成り立ち上必然的に生ずるものとテスト実施者の意図に由来するものの複合形テストケース区間. 発見障害件数 n=1 n=2 n=3 n=4 n=5 1, , , n : 重複の数累積発見バグ数 ( 個 ) 実施テストケース数 ( 件 )

22 本セッションの構成 0. はじめに 1. バグ曲線収束理由の検討 2. 収束理由を踏まえたバグ曲線の活用 3. おわりに

23 収束理由を踏まえたバグ曲線の活用ここまでで確認したこと次の2つはバグ曲線収束の原因となりうる 1テストケースの成り立ち上必然的に生ずるもの重複 2テスト実施者の意図に由来するもの意図原因は他にもあるかもしれないしかしバグ曲線を活用するテスト管理において少なくとも2つの意識すべきポイントを得た

24 収束理由を踏まえたバグ曲線の活用過去のバグ曲線の傾向や信頼度成長曲線を用いた分析を行う際には以下の注意が必要重複テストケーススイートの網羅性が不十分でも重複していれば収束に向かう意図テスト実施者や実施環境によってテスト実施順が変わり異なるバグ曲線となる可能性がある

25 本セッションの構成 0. はじめに 1. バグ曲線収束理由の検討 2. 収束理由を踏まえたバグ曲線の活用 3. おわりに

26 おわりに本セッションではテストケーススイートが存在する場合のバグ曲線について検討した先の繰り返し過去のバグ曲線の傾向や信頼度成長曲線を用いた分析を行う際にはテストケース作成やテスト実施順に注意が必要

27 おわりに本セッションではテストケーススイートが存在する場合のバグ曲線について検討したではベータテストや運用テストのような個々のテストケーススイートを前提としないテストの場合はどうだろうか? テストケースとか恣意とかあまり意識しない

28 おわりにベータテストや運用テストテストケースとか恣意とか意識せずどれだけの期間やるかがポイント横軸はテストケースでなく時間でよい普通の信頼度成長モデルが使えるのでは?

29 おわりに ( おまけ ) 今回 Excel 関数で検討したのはバグ曲線での管理を指示する方々の PC には Excel が必ず入っているだから一緒にその特性を考えて欲しいのです

30 ということで最初に帰って

バグ曲線はどうして寝るのでしょうか? Thank You! E-mail: niwa.takeo@jri.co.

31 バグ曲線はどうして寝るのでしょうか? Thank You! The opinions expressed in this presentation are solely those of the presenter and do not necessarily reflect the opinions of any organization.