「Software Test & Quality Advent Calendar 2011」に、12/14(水)担当として参加させていただくことにしました。
前日は、goyoさんの「テスト自動化をサポートするDVCS」です。
みなさんの素敵なエントリの間に、地味でレガシィな雑談を滑りこませます。
分量の割に内容は薄く、要点は以下の2点です。
- 由緒ある品質の技法をあらためて召喚するのも面白い
- 現場の足枷にならない、役に立つメトリクスの使い方があるといいね
「欠陥数予測」のウケの悪さ
ソフトウェアの欠陥の数を予測する話・・・などと口走った瞬間に警戒されますよね。特に「欠陥密度」を嫌う人は少なくないようです。
なぜ、嫌われるのか。考えてみると、以下のような三つのドグマが、その理由になっているように思います。
- 欠陥の数は、ソフトウェアの LOC に正比例するっ・・！
- その比例定数は、個々のプロジェクトに依存しないっ・・！
- その予測結果を、摘出の目標とすべきであるっ・・！
・・・まあ極端に書いてますし、これを絶対的に盲信している人はあまりいないでしょう。
一方で、「テストの終わり」の基準として何らかの数字が欲しいのも人情。そのため、これほど極端ではなくとも、どうにもしっくりこない「目標」が独り歩きしてしまうことがありそうです。
欠陥数を予測する技法として、もう少しこのドグマから逃れられるものはないでしょうか。
「探針」と、勝手な実験
探針とは何か
『SQuBOKガイド』の知識エリア3.6「品質分析・評価の技法」に、「探針」（Quality Probe）という項があります。
- 作者: SQuBOK策定部会
- 出版社/メーカー: オーム社
- 発売日: 2007/12
- メディア: ペーパーバック
- 購入: 9人 クリック: 150回
- この商品を含むブログ (33件) を見る
このエントリを書こうと思い立って改めてネットを調べたところ、すでに秋山浩一さんが、この探針について必要十分な記事を書かれていて、目の前が真っ暗になりました。詳細はこちらをご覧いただくとして。
探針とは、ハードウェア製品でいう抜き取り検査のアナロジーです。製品全体から一部を抜き取って、その不良の割合から全体の品質を予測する。
ソフトウェアでは、「製品」を「テストケース」に読み替えます。
検査部門が、用意したテストケースから一定の割合の項目を無作為に選び取り、消化する。その結果から、テストケース全体で出るであろう欠陥の数の範囲を予測するのです。
この予測には、区間推定の考え方を使います。「開票が始まったばかりなのに当確が出る」「ほんの一部の世帯しか調べていないのに視聴率が出る」というのと、本質的なところは変わりません。
主な変数は2つだけ。消化したテストケースの数と、摘出した欠陥の数。たとえば、全テストケース5,000件の中から30%選んで消化した結果、欠陥が50件だったとすると、全テストケースでは121～212件の欠陥が出ると予測されます。
工程全体ではどうなるか
探針による予測は、テスト工程のどこかの一時点で行うものとされています。でもためしに、テスト工程の進捗の各段階で予測をしたらどんな姿になるか、見てみましょう。*1
日付を横軸にして、欠陥の摘出がまんま Gompertz 曲線に乗るような、40日間のテスト工程で試してみます（土日もテストやってる！とか気にしないでください。欠陥数も適当）。
わー！最初の2週間くらいでもう、最終的な欠陥数の範囲にほぼ収束してる！すごい！
開始直後はテストケースのサンプル数が少ないので、上下限の幅はとても広いのですが、急速に狭まり、予測が安定していますね！
というのはもちろん欺瞞。このグラフでは、「消化したテストケース数に比例して欠陥が出る」というシミュレーションをしています。
探針でのサンプリングは、（層別で）無作為が原則です。欠陥のありそうなところから優先度をつけて叩いていく、という戦略のもとでテストを進めている場合は、無作為ではないですね。
一方、そういう戦略ナシで、各チームが並行に、担当分のテストケースを作った順に消化していくような場合は、ある程度の無作為性があるようにも思います。逆説的ですが、テスト戦略なく進めている方が、うまく理論に乗る、なんてことがありそうです。
いずれにせよ、技法なりメトリクスなりを適用するには、前提を押さえておくことが肝要ですね。
三つのドグマとの関係
探針の変数
さて、欠陥密度と同様、探針による予測も素朴なものです。ですが実は、最初に述べた(1)と(2)のドグマからは解き放たれています。
(1)について、ソフトウェアの「大きさ」の概念が出てきません。
(2)についてはどうでしょう。「テストケース数」と「摘出された欠陥数」という、2つの変数について考えてみます。
当然ながら、ソフトウェアの品質が低ければ欠陥が多く出るでしょうし、テストケースがいまいちなら、出るべき欠陥が出せません。
つまり「欠陥」は、プロジェクトやソフトウェアの性質、設計・実装チームのスキルといった要素が織り込まれたもの。「テストケース」は、テストチームのテスト戦略、テスティングスキルが織り込まれたもの。
ものすごい単純化かも知れませんが、探針による予測には、その開発独自の要素が織り込まれており、プロジェクト固有の指標になっているのです！・・・いるのかもしれないのです（言い直した）。
区間の捉え方
では、予測した上限・下限をどう使うべきなのでしょう。
探針本来の目的として、『SQuBOKガイド』には、「品質の早期把握と品質向上施策の指針を得る」とあります。保田勝通氏・奈良隆正氏の『ソフトウェア品質保証入門』でも同様です。短絡的に、「この範囲を目標として欠陥を出すのだ！」とは言っていません。(3)のドグマからも自由になれそうです。
ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点
- 作者: 保田勝通,奈良隆正
- 出版社/メーカー: 日科技連出版社
- 発売日: 2008/05/01
- メディア: 単行本
- 購入: 4人 クリック: 20回
- この商品を含むブログ (7件) を見る
ここでちょっと目先を変えて、この区間を、「リスクの幅」と考えることはできないでしょうか。品質的なリスクではなく、テスト工程に要する工数の不確定要素ということです。
欠陥が多ければ、それだけ改修の人と時間を要する。テスト工程の途中段階で、欠陥数の最良と最悪がざっくりとでも把握できていれば、何やら嬉しさがあります。
また、この区間推定はけっこう、傾向の変化に敏感のようです。ためしに、上のグラフの欠陥数のうち4/16だけ5件増やすと、こうなります。
2011年4月16日(土)休日出勤中のテストエンジニアの苛立った顔が目に浮かぶようですね。
このように、テスト工数のリスクと、傾向監視に使うことができそう。とも思います。
おわりに
以上、一般にあまり知られた技法ではない「探針」の紹介と、勝手な実験をしてみました。
テスト工程の状況から欠陥数を予測するといえば、まずソフトウェア信頼度成長モデルがあり、『SQuBOKガイド』でもちょうど、探針の直前に来ています。この Advent Calender でも太田さんが、Gompertz 曲線はアジャイル開発で使えるかというエントリーを書かれていました。
アジャイル開発でも信頼度成長曲線は有効か？ツールを使って確かめてみようootaken.wordpress.com
こんな風に、古式ゆかしい技法を、現代の開発の現場でうまく使えないものかと考えてみるのも、面白いのではないでしょうか。
机上の空論に終わらない、そして現場の助けになれるような技法やメトリクス。そんなものを見つけていけたらいいなと思い、こんなエントリーを書いてみました。
最後まで読んでいただき、ありがとうございます。
明日12/15(木)は、Shuji Watanabeさんの予定です。
*1:これ以降の話は本来の「探針」とはまったく関係なく、わたしの個人的な思いつき、実験に過ぎません。
