21日目：バグ密度・テスト密度に依存しない品質保証への挑戦

はじめに

このAdvent Calendarでは、過去に私が書いたテストや品質に関する記事の紹介をします。
本日紹介する記事はこちらです。

https://www.nttdata.com/jp/ja/trends/data-insight/2021/0204

掲載日：2024年1月23日
掲載メディア：DATA INSIGHT（NTT DATA）

生成AIによる要約

この記事では、従来品質管理でよく使われてきた「バグ密度」や「テスト密度」といった指標が、近年の多様な開発手法や技術の変化によって限界を迎えていると指摘しています。たとえば、言語やフレームワークが変わる、ノーコード／ローコード・クラウド・AIなどを使うケースが増えるなど、以前のように「同じ条件」で比較できるプロジェクトが減少してきたためです。これらの背景を受けて、同社では定量指標に頼らず、より実態に即した品質保証手法を開発。具体的には、「観点カバレッジ」（どの観点でテストしたかをマッピングする） と 「DDPモニタリング（欠陥検出率モニタリング）」 を組み合わせる方式を提案・実践しています。これにより、テスト量だけでなく「どんなテストをしたか」「どれだけバグを捕まえたか」の両面から品質管理を行えるようにする、というのが本稿の主張です。

記事に対する補足、訂正、最新情報など

• この記事はもともと、2021年2月に私とは別のメンバーが執筆したものが公開され、アクセスランキングの上位に長くランクインしていました。そのこともあり、内容を最新化してほしいという要望が出ましたが、元の執筆者が退職していたため、私を含む3名で加筆・修正を行いました。
• 記事の主題となっている「バグ密度やテスト密度を使った品質管理には意味がない」という問題意識は、私がソフトウェア開発や品質管理に携わる中で、以前から抱いていた違和感に基づくものです。単なる数字合わせのようになっていたり、実際には定性的な分析結果で結論づけているにもかかわらず、これらのメトリクスだけが“神格化”されているように扱われる状況を不思議に感じていました。
• とはいえ、「バグ密度やテスト密度には意味がない」というのは言い過ぎであり、一つの目安として有用な場面もあります。ただ、それだけでは不十分であるにもかかわらず、過度に依存してしまっている状況に危機感を持っていました。
• 弊社でもこれらの指標は長らく使われてきましたが、「そろそろ見直しませんか」という提案を、おそらく2012〜2013年ごろに行いました。その際、私はテスト対象の仕様に基づいて網羅性（カバレッジ）を厳密に測る手法を検討しましたが、工数がかかりすぎることや、テスト設計の自由度が下がることなどの理由から、あまりうまくいきませんでした。
• その後、別のメンバーが、この記事で紹介しているような比較的ライトな方法を考案し、社内で活用されるようになりました。現在はその手法を私が引き継いでいます。自分が最初に試みた方法はうまくいかなかったので複雑な思いもありますが、当初の問題提起が形を変えつつも実を結んだことには、大きな充実感も覚えています。
• 加筆・修正した記事では、私が現在専門としているアジャイル開発への適用可能性についても触れています。
• 本記事に関しては社外からのお問い合わせも多く、弊社の広報・営業などを経由してご連絡をいただき、内容をご説明させていただく機会も増えています。

さいごに

私自身は、この記事でも紹介している観点カバレッジと、上で触れた仕様に対するカバレッジが特に重要だと考えています。品質保証とは最終的には「お客様の要求を満たしていることを示すこと」ですので、それをできる限り論理的に説明したい、というのが私の目標です。これまでに培ってきたさまざまな技術や経験を組み合わせて、これまでの知見を統合した方法論としてまとめ上げたいと考えています。

ここまでお読みいただき、ありがとうございました。明日の投稿もどうぞお楽しみに。