不意にブログオラクルが降りてきたので、書き殴っておきます。
「距離」パラダイムと「追随」パラダイム
先日のブログ記事で、こんなことを書きました。
ユーザ要求の変化に追随する能力が、アジャイル開発における品質のメトリクスの1つとなる。
従来型の品質メトリクスって、「理想と現実がどれだけ離れているか」を測ろうとするものなんですよね。
たとえば「プログラムに含まれる欠陥の数は、ソースコード行数におおよそ比例する」というシンプルな仮定のもと、「欠陥密度」というメトリクスがある。その密度には一定の目指すべき値があって、その値を達成すれば十分な品質と見なすことができる、みたいな感じですね。
で、わたしもその「理想と現実の距離」パラダイムに浸かっているので、アジャイル開発における品質メトリクスに見られる「変化への追随」パラダイムに、最初はすごく違和感を覚えていました。
「テストの十分性」という難物
そんな時に、テスト業界三大難問の1つ・「テストの十分性」*1についても同じことが言えるのではないかと、ふと思いました。
「距離」パラダイムだと、ある時点において「テストが十分と言える値」があり、そこを目指そうということになります。
「テストケース密度」というメトリクスは、その代表です。プログラムの規模単位あたりのテストケース数で、十分性の代替指標としている。
では、「追随」パラダイムにおける「テストの十分性」メトリクスには、どんなものが考えられるでしょうか。
ぱっと思いつくものを、3つ書いてみます。
(1)リグレッションテストの自動化率
機能追加や仕様変更に伴ってテストケースが追加・修正されると、手動テストケース数が増え、自動化率を低下させることがあります。そのテストケースを迅速に自動化し、自動リグレッションテスト実行の仕組みに組み込み、安定的に流せるという能力は、「テストの十分性」の代替指標になりえます。
ただし、Garbage In, Garbage Outと呼ばれるように、元のテストケースの質が低ければ、自動化したところで質は低いままですが。
(2)「意図せず見つけた」欠陥の割合の減少
開発中に見つかる欠陥のすべてが、テストケースで意図して見つけようとしたものとは限りませんよね。全然違うテストの実行中だったり、なんならテスト環境構築中に見つかる欠陥だってあります。
もちろん、その手の欠陥を見つけられたのはラッキーだし、目ざとく拾ってくれたメンバーには感謝！なのですが、幸運だけに頼るのは心もとない。
その偶然見つけた欠陥が、自分たちの持っているテストセットでは検出できなかったとわかった場合は、どのようなテスト観点・テストケースが漏れていたのかを逆算し、必要に応じてテストセットに組み込んでいくのがよいでしょう。
これを繰り返していくと、「意図せず見つけた」欠陥の割合が安定して減っていくことが期待できます。この減少具合は、テストの十分性が改善できている指標と言えそうです。
もちろん、機能追加などに伴ってテスト対象が増えると、一時的に「意図せず見つけた」欠陥の割合は悪化する可能性があります。この推移を観察するのは、けっこう面白そうじゃないですか？*2
(3)リグレッションテストでの欠陥の流出率の改善
流出率はたとえば、 リグレッションテストで検出できた欠陥と、流出させてしまった欠陥の比率 のように算出するイメージ。
リグレッションテストで可能な限り（いわゆる）デグレを検出したいので、流出率が低くなっていくのは「十分性」が成長していると言える、気がする。
ただ、リグレッションテストは多ければ多いほど良いというわけでもないので、リグレッションテストが「必要十分」な数であることも把握できるといいですね。これはまた別のメトリクスになるでしょう。
いかがでしたか？ いかがでしたか？ いかがでしたか？
あまり深く考えずに書いている（言い訳が多い）ので、すでにバッドプラクティスだとわかっているようなことを主張していたら、教えてください。
