なぜバグ曲線は収束するのか～Microsoft Excelを使って考えてみる～

JaSST‘13 Tokyo
２０１３年１月３１日

丹羽 岳雄
株式会社日本総合研究所

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

JaSST '13 Tokyo， Takeo Niwa

バグ曲線で“よく”議論されていることより良いモデルの構築？

曲線収束の判定方法？

最適なモデルの選択方法？
横軸は、時間？工数？
テストケース数？

なにか 足りない・・・
JaSST '13 Tokyo， Takeo Niwa

バグ曲線で“よく”議論されていることあまり議論されている感じがしないこと

バグ曲線はなぜ寝るの？

JaSST '13 Tokyo， Takeo Niwa

本セッションの構成
０．はじめに
１．バグ曲線収束理由の検討

２．収束理由を踏まえたバグ曲線の活用
３．おわりに

JaSST '13 Tokyo， Takeo Niwa

バグ曲線収束理由の検討
バグ曲線が収束するとは、結果論として、バグがテスト期間の始めの方でたくさん見つかっているということ

ならばそれを考えてみよう
JaSST '13 Tokyo， Takeo Niwa

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

JaSST '13 Tokyo， Takeo Niwa

テストケースの成り立ち上必然的に生ずるもの

い ろ はに ほへ とＡ

B

C

TestCaseNo.
１
２３４
５
６
７
８
９１０

JaSST '13 Tokyo， Takeo Niwa

確認したい項目
いろはにほへとＡＢＣ

テストケースの成り立ち上必然的に生ずるもの

Ａ は、No.８の前にNo.１～４の４つのテストケースで事前に確認されてしまう

い ろ はにＡ

TestCaseNo.
１２３４５６７８９１０

JaSST '13 Tokyo， Takeo Niwa

確認したい項目
いろはに
ほへとＡ
ＢＣ

テストケースの成り立ち上必然的に生ずるもの
Ａ を確認するためのNo.８のテストケース実行前に、No.１～４の４つのテストケースでＡについて事前に確認されてしまう個々のバグを発見できるのは、その部分の確認を意図するテストケースだけとは限らない。

個々のバグを発見できるテストケース数が多ければバグ発見が早くなる（のでは？）
JaSST '13 Tokyo， Takeo Niwa

個々のバグを発見できるテストケース数が多ければバグ発見が早くなる（・・・のでは？）“テストケーススイート１"- テストケース １００００件
- バグ
２００件
条件１

各バグは１つのテストケースのみで発見 【重複無】条件２

各バグは３つのテストケースで発見【３件重複】

条件３

各バグは５つのテストケースで発見【５件重複】

JaSST '13 Tokyo， Takeo Niwa

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

個々のバグを発見できるテストケース数が多ければバグ発見が早くなる（・・・のでは？）- テストケース １００００件
- バグ
２００件
は、それぞれの関数を２００回実施して得られる値を昇順に並べて累積的にグラフを描けばバグ曲線が得られる

条件１

各バグは１つのテストケースのみで発見 【重複無】RANDBETWEEN (1,10000)

条件２

各バグは３つのテストケースで発見【３件重複】MIN ( RANDBETWEEN(1,10000), RANDBETWEEN(1,10000),RANDBETWEEN(1,10000))

条件３

各バグは５つのテストケースで発見【５件重複】MIN ( RANDBETWEEN(1,10000), RANDBETWEEN(1,10000),RANDBETWEEN(1,10000), RANDBETWEEN(1,10000),RANDBETWEEN(1,10000))JaSST '13 Tokyo， Takeo Niwa

個々のバグを発見できるテストケース数が多け
ればバグ発見が早くなる
条件1 : 各エラーは１つのテストケースのみで発見

条件2 : 各エラーは３つのテストケースで発見

線形

条件3 : 各エラーは５つのテストケースで発見収束でしょう。

寝てきた?

テストケーススイート内に、同一バグを発見できる
テストケースが多いほどバグ発見は早くなる
JaSST '13 Tokyo， Takeo Niwa

テストケースの成り立ち上必然的に生ずるもの
三段論法
あるテストケースが、「他の項目もテストしてしまう」

重複は収束理由になる

バグ発見は早くなる

バグ曲線は収束しやすくなる

JaSST '13 Tokyo， Takeo Niwa

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

JaSST '13 Tokyo， Takeo Niwa

テスト実施者の意図に由来するもの【バグを早く発見したいというテスト実施者の意図】・バグ原因となる箇所を予測したテスト
・恣意的な実施順の決定
ｅｔｃ
これらが上手くいけばバグ発見は早くなる

バグ曲線収束に貢献！
JaSST '13 Tokyo， Takeo Niwa

テスト実施者の意図に由来するものでバグ発見が早くなる（・・・とバグ曲線は収束するのでは？）
テストの早い段階ほど発見できるテストケースが、多いことは、例えば以下のように表すことができる。
テストケース区間.
１， ２０００

発見障害件数（重複無しとする）

２００１， ４０００

４０

４００１，１００００

２０

６００１，１００００

８９０

RANDBETWEEN (1,2000)
RANDBETWEEN (2001,4000)
RANDBETWEEN (4001,10000)
RANDBETWEEN (6001,10000)
JaSST '13 Tokyo， Takeo Niwa

がががが９０ 個
４０ 個
２０ 個
８ 個

テスト実施者の意図に由来するものでバグ発見が早くなりバグ曲線は収束に向かう（かな？）RANDBETWEEN (1,2000)
RANDBETWEEN (2001,4000)
RANDBETWEEN (4001,10000)
RANDBETWEEN (6001,10000)

がががが９０ 個
４０ 個
２０ 個
８ 個

まあ、収束していく形に見えるように値を選んだのだから・・・
自演と言えば自演。

JaSST '13 Tokyo， Takeo Niwa

バグ曲線収束理由の検討
検討する収束理由①テストケースの成り立ち上必然的に生ずるもの「ある項目をテストしようとすると、他の項目もテストしてしまう」②テスト実施者の意図に由来するもの【意図の例】
・バグ原因となる箇所を予測したテスト
・恣意的な実施順の決定③①と②の複合形
JaSST '13 Tokyo， Takeo Niwa

テストケースの成り立ち上必然的に生ずるものとテスト実施者の意図に由来するものの複合形
テストケース
区間.

発見障害件数ｎ=１ ｎ=２ ｎ=３ ｎ=４ ｎ=５

１， ３０００

１５１５１５１５３０３００１， ６００００

６６１２

１２６００１，１００００

８８８００ｎ ： 重複の数160140120
累積
発 100
見バ 80
グ数 60（個） 40
20001000

2000

3000

JaSST '13 Tokyo， Takeo Niwa

4000

5000

6000

実施テストケース数（件）

7000

8000

9000

10000

本セッションの構成
０．はじめに
１．バグ曲線収束理由の検討

２．収束理由を踏まえたバグ曲線の活用
３．おわりに

JaSST '13 Tokyo， Takeo Niwa

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

収束理由を踏まえたバグ曲線の活用
過去のバグ曲線の傾向や信頼度成長曲線を用いた分析を行う際には以下の注意が必要

重複

テストケーススイートの網羅性が不十分でも、重複していれば収束に向かう

意図

テスト実施者や実施環境によって、テスト実施順が変わり、異なるバグ曲線となる可能性がある

JaSST '13 Tokyo， Takeo Niwa

本セッションの構成
０．はじめに
１．バグ曲線収束理由の検討

２．収束理由を踏まえたバグ曲線の活用
３．おわりに

JaSST '13 Tokyo， Takeo Niwa

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

JaSST '13 Tokyo， Takeo Niwa

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

テストケースとか恣意とかあまり意識しない
JaSST '13 Tokyo， Takeo Niwa

おわりにベータテストや運用テスト
テストケースとか恣意とか意識せず、どれだけの期間やるかがポイント

横軸はテストケースでなく時間でよい
普通の信頼度成長モデルが使えるのでは？

JaSST '13 Tokyo， Takeo Niwa

おわりに（おまけ）今回 Ｅｘｃｅｌ 関数で検討したのは・・・

バグ曲線での管理を指示する方々のＰＣには、Ｅｘｃｅｌ が必ず入っている。
だから一緒にその特性を考えて欲しいのです。

JaSST '13 Tokyo， Takeo Niwa

・ ・ ・ ということで、最初に帰って。

JaSST '13 Tokyo， Takeo Niwa

バグ曲線はどうして寝るのでしょうか？
Thank You ！
E-mail: niwa.takeo@jri.co.jp
The opinions expressed in this presentation are solely
those of the presenter and do not necessarily reflect
the opinions of any organization.