ソフトウェアの品質を学びまくるソフトウェアの品質を学びまくる読者になるソフトウェアの品質を学びまくるソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。不意にブログオラクルが降りてきたので、書き殴っておきます。「距離」パラダイムと「追随」パラダイム先日のブログ記事で、こんなことを書きました。www.kzsuzuki.comユーザ要求の変化に追随する能力が、アジャイル開発における品質のメトリクスの1つとなる。従来型の品質メトリクスって、「理想と現実がどれだけ離れているか」を測ろうとするものなんですよね。「プログラムに含まれる欠陥の数は、ソースコード行数におおよそ比例する」というシンプルな仮定のもと、「欠陥密度」というメトリクスがある。その密度には一定の目指すべき値があって、その値を達成すれば十分な品質と見なすことができる、みたいな感じですね。わたしもその「理想と現実の距離」パラダイムに浸かっているので、アジャイル開発における品質メトリクスに見られる「変化への追随」パラダイムに、最初はすごく違和感を覚えていました。「テストの十分性」という難物そんな時に、テスト業界三大難問の1つ・「テストの十分性」*1についても同じことが言えるのではないかと、ふと思いました。「距離」パラダイムだと、ある時点において「テストが十分と言える値」があり、そこを目指そうということになります。「テストケース密度」というメトリクスは、その代表です。プログラムの規模単位あたりのテストケース数で、十分性の代替指標としている。「追随」パラダイムにおける「テストの十分性」メトリクスには、どんなものが考えられるでしょうか。思いつくものを、3つ書いてみます。機能追加や仕様変更に伴ってテストケースが追加・修正されると、手動テストケース数が増え、自動化率を低下させることがあります。そのテストケースを迅速に自動化し、自動リグレッションテスト実行の仕組みに組み込み、安定的に流せるという能力は、「テストの十分性」の代替指標になりえます。Outと呼ばれるように、元のテストケースの質が低ければ、自動化したところで質は低いままですが。開発中に見つかる欠陥のすべてが、テストケースで意図して見つけようとしたものとは限りませんよね。違うテストの実行中だったり、なんならテスト環境構築中に見つかる欠陥だってあります。その手の欠陥を見つけられたのはラッキーだし、目ざとく拾ってくれたメンバーには感謝!なのですが、幸運だけに頼るのは心もとない。その偶然見つけた欠陥が、自分たちの持っているテストセットでは検出できなかったとわかった場合は、どのようなテスト観点・テストケースが漏れていたのかを逆算し、必要に応じてテストセットに組み込んでいくのがよいでしょう。これを繰り返していくと、「意図せず見つけた」欠陥の割合が安定して減っていくことが期待できます。この減少具合は、テストの十分性が改善できている指標と言えそうです。機能追加などに伴ってテスト対象が増えると、一時的に「意図せず見つけた」欠陥の割合は悪化する可能性があります。ように算出するイメージ。リグレッションテストで可能な限り(いわゆる)デグレを検出したいので、流出率が低くなっていくのは「十分性」が成長していると言える、気がする。リグレッションテストは多ければ多いほど良いというわけでもないので、リグレッションテストが「必要十分」な数であることも把握できるといいですね。これはまた別のメトリクスになるでしょう。いかがでしたか?あまり深く考えずに書いている(言い訳が多い)ので、すでにバッドプラクティスだとわかっているようなことを主張していたら、教えてください。Midjourney*1:あと2つは知りません。誰か提案してください。*2:分析の手間だけでなく、バグチケット起票の際の手間という副作用があります。AdSenseを使用しています。AdSenseは、ユーザーの興味に応じた広告を配信するためにCookieを利用しデータを収集しています。Cookieを無効にする設定、およびGoogleアドセンスに関する詳細は、Googleのポリシーと規約をご覧ください。はてなブログをはじめよう!kz_suzukiさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。