つれづれなる技術屋日記

しがない技術屋。専門は情報工学で、「つれづれ技術屋」って呼んで。

「コーダーとテスターのパラドックス」

昨日Twitterのつぶやきで、信頼度成長曲線の話しにちょっと反応。こちらは、むしろテスト件数などの理想カーブに注目すべきと思って書いたけど、元々品質を測る信頼度成長曲線に注目してたようだ。って、元々そう書いてあったと言えば、そうなんだけど、、、。

 

で、ふと思ってこっちに補足的なことも含めて書いとく。

 

まずタイトルは、「アキレスと亀」をもじったもの。”コーダー”とせずにソフト開発者としても良いかもしれないけど、語韻と開発よりも製造に近いイメージがあるので、”コーダー”。ここでの”テスター”は、第三者検証のようなコーダーや設計/開発とは別チームでの検証の人。

 

アキレスと亀」って、”ゼノンのパラドックス”とか”ゼノンの逆説”の中の一つで、ウィキなどにも書かれてる。 

 

http://ja.wikipedia.org/wiki/%E3%82%BC%E3%83%8E%E3%83%B3%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9

 

あるところにアキレスと亀がいて、2人は徒競走をすることとなった。しかしアキレスの方が足が速いのは明らかなので亀がハンディキャップをもらって、いくらか進んだ地点(地点Aとする)からスタートすることとなった。

 

スタート後、アキレスが地点Aに達した時には、亀はアキレスがそこに達するまでの時間分だけ先に進んでいる(地点B)。アキレスが今度は地点Bに達したときには、亀はまたその時間分だけ先へ進む(地点C)。同様にアキレスが地点Cの時には、亀はさらにその先にいることになる。この考えはいくらでも続けることができ、結果、いつまでたってもアキレスは亀に追いつけない。

 

この話は、高校の数学で取り上げられるケースが多い。無限級数とか収束。ネットで検索すると分かりやすい解説もあるので、興味あればそちらを。

 

 

で、ソフトウェアテストとの関係。アリストテレスをコーダー、亀をテスターと置き換える。そして、スタート地点でのことをテスターに最初に渡すバージョンでの何行かのソフトウェア、スタート後もバグ対策で何行かソフトウェアを作成すると考える。すると、追い越せるかは、テストが完了=バグ修正の行数がゼロになるかと考えればよい。無限に続きそうに思える点が、ゼノンの逆説とも似てくる。(テストでは、スピードを一定と考えるべきじゃない点は後述。)

 

ちなみに、ソフトウェアでの理想的なこの類を考える時の前提としてはいくつか考えられる。

 

1)バグはゼロ

 

理想という点では分からなくもないが、非現実的。

 

2)バグは均一

 

3)ソフトの生産性(修正スピード)は一定

 

4)テスト件数のスピードは一定

 

従来の信頼度成長曲線って、3)とか4)はあまり議論せずに、バグ残件がどのカーブにフィットするかの議論が多い。残件は終盤でゼロに近いので、成長曲線の類になるのは当然だが。それはそれで価値があるが、それを理想モデルと言うべきかは疑問のあるところ。また、検証サイドとしては、4)のテスト処理がスムーズに行われない原因を探るべきなのに、(論文や記事が信頼度成長曲線に関するものがほとんどなので)残件バグのカーブの方に目が行ってしまう。そんな気がする。

 

ゼノンの逆説の解法で分かりやすいのは、横軸が時間で縦が距離のグラフ。ただし、ソフトウェアテストのコーダー側の場合は、縦を行数として、追加行数を考える必要がある。コーダーの生産行数(スピード)はテスト結果の反映を考えて、テスト開始(t0)から追加行数自体は次第に減衰する。t1には、t0からt1直前までに発見されたバグ対策に相当する行数を生産していることになるため。これは(理想モデルでは)等比級数でOK。ゼノンの逆説でのイメージでは、アリストテレスは疲れてきて段々スピードが遅くなるイメージ。

 

ソフトウェアテストのテスター側は、横軸が時間で、縦軸が件数。これは直線で良いだろう。(回帰テストのことがあるけど、処理件数という点ではスピードは一定が理想。) 等比級数等比数列の項の総和)は求まるので、バグ率によりトータル行数も算出できる。もちろん、テストが追い抜く時期も判明する。

 

ここでのテスター側は、回帰テストも含めてテストスピードが一定であることを前提としているが、ある意味目標かもしれない。Twitterでの返信でも書いたけど、そもそもテストの粒度の扱いをどうするかが悩ましく感じる人もいるかもしれない。また、いかに回帰テストを効率よくやるかも目標だろう。

 

なお、冒頭でバグゼロが非現実的と書いたけど、(第三者検証に対しては)バグゼロに近づける事を目指していることや、実際近づきつつあるのは事実。テストツールでの事前確認もそうだし、イテレーション毎に出荷できるリリースを目指す開発手法なども普及しつつある。なので、ここで述べた追いつくまでの期間や修正行数が、ゼロに近づきつつあるとは言える。

 

 

いわゆる信頼度成長曲線で(開発の)状況を分析するのは良いことだと思う。自分自身はアンチ信頼度成長曲線派でもなく、使うべきとの考え。また、対数曲線や二次曲線での近似も悪くないことを、このブログでも書いた。(「バグカーブ 対数曲線や二次曲線での近似のお勧め」) 

 

バグカーブ 対数曲線や二次曲線での近似のお勧め - つれづれなる技術屋日記

 

ただ、信頼度成長曲線は信頼度を示すけど、ソフトウェアテスト自体の状況を示している訳じゃない。ソフトウェアテストの状況を知って改善するには、別の指標での監視が必要だし、理想での指標を頭にイメージしておくべきと言える。

©2005-2020 ほんだ事務所(honda-jimusyo) All rights reserved.