metrics - QAの改善を示す

Question

上級管理職は、各グループが年々改善を示すことを望んでいます（つまり、意見を述べるだけでなく、データで利益を示す）。QAの改善をどのように示しましたか？どのような指標を使用しましたか？

これは、あるテスターを別のテスターよりも評価することではありません。それは、部門の成長を示し、個々のテスターに​​個人の改善を強調する能力を提供することです。

Answer 1

QA部門が何をしているのかを明確にすることが重要です。これは会社によって多少異なりますが、最終的にはQAはデータ収集操作です。1人/プロジェクトごとに提出されたバグの数は簡単に測定できますが、QAチームが行っている作業の量やその効果とはほとんど関係ありません。

QAによって発見されたバグと比較して、リリース後に顧客によって発見された重大なバグの割合を確認することをお勧めします。テストが改善されると、この数は減少するはずです。また、各リリースに対して実行されたテストケースの数を測定します。QAプロセスが成熟するにつれて、テスターの生産性が向上するはずです（親しみやすさ、または自動化によって）。

Answer 2

発見されたバグを含め、見当違いの QA 指標が多数あります。これはとても簡単なことですが、ソフトウェアがそれほど変更されていなければ、時間の経過とともに発見されるバグの数はゼロになる傾向にあります。

個々のテスターと彼らが提起したバグの数を測定することは、競争力のあるタイプの間でインセンティブを提供する方法ですが、多くの小さな問題も提起される可能性があります (これは良いことでも悪いことでもあります)。

考えられる有用な指標には次のものがあります。

• フィールドで見つかった新しいバグ (つまり、見逃したもの) の測定数 - これは下がるはずです
• 修正された問題を再テストしてクローズする時間
• 明確にするために返送されたバグの数 (減少するはずです)
• 無効なテスト アサーションのために閉じられたバグ レポートの数 - 理解を示し、減少するはずです

目標も指定されている場合 (自動テスト システムに移行するなど)、それが測定方法になります。したがって、10,000 個のテスト ケースがある場合、メトリックは、自動化されたテスト ケースの数、合格/不合格の数になります。

これについては、非常に優れた記事があります: http://www.claudefenner.com/content/detail/QAMetricsPage.htm

Answer 3

発見されたバグがどれほど洗練されているか。たとえば、Web ページをロードするだけでクラッシュするという単純なものか、それともエラーを再現するのに多くの手順が必要か、それがどのように進行するかを見るために使用される 1 つの指標になる可能性があります。ただし、開発者が最初にソフトウェアをどれだけうまく構築するかに多少依存します。

開発者がバグを理解するためだけに QA と組み合わせて何時間も費やしているかのように、明確化のためにバグが送信される頻度も役立ちますが、それは時間を費やす最も有益な方法ではありません。

最後に、誰かがここで QA 101 のマニュアルを作成して、いくつかのプラクティスと知識を書き留めて時間をかけて改訂し、さまざまなテスト プラクティスを理解し、状況に役立つものを採用するという点で成長を示すことができるようにすることは価値があるかもしれません。それらは私の提案です。

Answer 4

報告されているバグ：修正されているバグの比率によってQAチームのパフォーマンスを測定する最良の方法だと思います。バグのほとんどがdevによって修正されている場合は、注意が必要な高品質のバグを見つけていることを示しています。無効なバグの数は、この種のバグが開発者の時間を浪費するというマイナスの尺度になるはずです。