欠陥密度はQAまたはDEVの有効性を測定しますか？
ほとんどの欠陥密度メトリックは次のとおりです。
バグの数/サイズ（KLOC、ストーリーポイント、機能ポイント..）
私はそれがQAの有効性を測定することを読みましたが、それはわかりません：
- 私は超上級の開発者とずさんなQAを持つことができます。したがって、ずさんなQA担当者は何もないので何も見つかりません。
- 私は悪い開発者と、ほとんどの問題を見つける良いQAの人を雇うことができます。
したがって、これはQAをどのように測定できるでしょうか？私の見解では、開発の質とQAの有効性の両方を反映しています。
QAの有効性を測定することを読みましたが、わかりません
きめ細かいメトリクスについては、そのような声明を出すことは確かに良い考えです。
特定のメトリックを使用してQAの有効性を測定する唯一の方法は、同じコードを使用して、それを別のQA担当者に渡して、個別に許可することです試して。理論的には、見つかったバグが多いほど、QAは向上します（ただし、実際には見つかったバグの重大度も組み込む必要があります）。
もちろん、そうすることでコードのサイズが固定されるため、密度を数値として使用してもまったく意味がありませんが、実際には「QAによって検出されたバグの数」をメトリックとして使用できます。
自分で正しく確認したように、QA担当者とテスト対象を変更するとすぐに、メトリックはQAの有効性について信頼できることを何も示しません。
この疑わしい声明を見つけた場所については何も言及しなかったので、簡単なウェブ検索を行って、他の人がこのメトリックについて書いた内容を確認しました。それは私に このページ をもたらし、欠陥密度メトリックの2つの使用法に言及しました：
さまざまなソフトウェアコンポーネントの欠陥の相対数を比較して、リスクの高いコンポーネントを特定し、リソースをそれらに集中させることができます。
ソフトウェア/製品を比較して、各ソフトウェア/製品の品質を定量化し、リソースを品質の低いものに集中させることができます。
「QAの有効性」はどこにも言及されていません。したがって、このソースによると、欠陥密度はソフトウェアの品質面を定量化するための指標であり、開発またはQAプロセスの指標ではありません。
（そして、あなたが教科書で何か違うものを読んだら、彼らは彼らの発言で彼らが何を考えていたかをその本の作者に尋ねる方が良いでしょう。）
欠陥密度は、コード測定の単位ごとに検出された欠陥の数を測定します（このためにコード行を決して使用しないでください）。数値が大きいほど、バグの密度が高くなります。
バグの密度は、アプリの品質の逆の尺度と見なすことができます。密度が低いほど（つまり、報告される欠陥が少ないほど）、コードの品質は高くなります。
しかし、単純なメトリックであるため、欠点があります。
- 単にコードをテストしない場合、私の欠陥密度はゼロです：完璧な品質！もちろん、実際には、ほとんどのテストされていないコードは、高品質ではありません。
- 逆に、同じコードに対して、熱狂的な開発者がいくつかのテストを依頼するよりも、非常に熱心なテスターから報告される欠陥の方がはるかに多くなります。そのため、1つのコードに2つの密度（つまり2つの品質測定）があります。発生した欠陥の数でそれらのテスターを判断しているので、品質をできる限り低く評価するように彼らにインセンティブを与えています。
- そしてもちろん、初期テストの問題もあります。スプリント中に開発者とテスターをペアにすると、バグが少なくなる可能性があります。しかし、スプリント中に発見された欠陥が記録される可能性は非常に低いため、測定基準を得るためだけに再テストしない限り、品質を測定することはできません。
欠陥密度は単なる指標です。さらに詳しく読むことができるようにするには（コードの品質、テストの効果、アプリに重大なバグが含まれている可能性など）、かなりの主観が必要です。テストがどれほど効果的であるかを知らない限り、欠陥密度は、たとえば信頼できる品質尺度にはなりません。しかし、メトリックを使用してテストの有効性を測定できない場合、どのように測定しますか？したがって、主観的な測定が必要です。
おそらく、見つかった欠陥を参照していた後リリース。つまり、QAではないユーザーによるものです。
この場合、不十分にコード化された作業はバグを見つけやすく、リリースするのではないため、これはQAの有効性の尺度です。非常によくできていますが、完全なコードではありませんが、いくつかのマイナーなバグが見つかる可能性がありますが、多くはありません。
もちろん、プロジェクトマネージャー-バグよりもデッドラインについてのケアも測定できます