テスト/テスターの効率の良い尺度は何ですか？

私は、QA組織としてのテスト効率の測定に関する経営陣との議論に参加しようとしています。この背後にある主な理由は、私たちのチームの半分が外注されており、私たちのビジネスは私たちがどれほど効果的/効率的であるかのいくつかのメトリックを提供したいので、私たちは請負業者のサービス契約と契約パラメータを交渉するための基礎データを持っている。

このテーマについて私が見つけた意見のほとんどは、開発者の効率性に関するものです。コードの行、配信されたストーリーポイント、導入された欠陥などです。

しかし、テスターはどうですか？テストは主に要件ベースで、手動、半自動、自動のテストが混在しています（すべてを自動化していないためではなく、テストシステムで自動化できないものがあるためです）。

書かれたテストの数は無用であり、発見された多数のバグは、効率的なQAではなく、不十分な開発の尺度になります。

自動化対策（コードカバレッジ、機能カバレッジなど）は良い場合もありますが、それらは開発者（開発者として、何かを誤って壊したかどうかを知ることができます）よりも顧客（私はそれをやりたい動作しません）。

顧客が問題に遭遇しなければ品質は良いので、QAチームとプロセスの有効性（効率ではなく）の適切な尺度は、QA によって発見されていない顧客によって発見されたバグの尺度です。

そのメトリックの主な問題は、実行された作業と意味のある数字を取得し始めるまでにかなりの遅延が発生する可能性があることです。

QAを評価するために前回の仕事で使用したいくつかの指標があります。

• 見つかったバグの数。私はこれが嫌いです。開発者にとっては、「書かれたコードの行数」のようなものです。
• 生成された自動テストケースの数。
• 機能テストでカバーされたアプリケーション全体の割合。
• ステージングと実稼働で見つかったバグの数。

最終的に、QAチームの仕事は、バグが野生に出る前に見つけることです。それらのメトリックは、実際にその目標を達成することに基づいている必要があります。テストケースのカバー率が低く、自動化されたテストの量が最小で、本番環境でバグが多い場合、それらはうまく機能していません。ただし、prodをヒットするかなり前にバグを見つけたという実績がある場合、メトリックはかなり高いはずです。

QAは、2つの主要な指標で測定する必要があります。QAを過ぎて現場で発見されるバグの数はいくつですか。彼らの重症度は？

dev-completeよりもリリースに近い重大なバグを見つけるためにQAを書き込める場合があります。（機能ごとに）推定完了日までにテストを完了していない場合、QAを確認できる場合があります。

最終的には、契約スタッフを使用することで得られる節約よりも、契約スタッフの有効性を測定するために多くのお金を費やすことになると思います...

私が働いている会社は、いくつかのQAメトリックを使用しています。

最も重要だと思うのは、コードカバレッジです。EMMAのようなツールは、手動テストに加えて徹底的な自動化されたテストを作成するので、非常に効果的です。

何をするにしても、テストの数に焦点を合わせないでください。これは1日あたりLOCとほぼ同じくらい便利です。

プロジェクト実行中の開発およびテスト段階でパフォーマンスを測定する多くの方法。私たちはプロジェクトで以下の手段を使用しました。4つの一般的なコードメトリック（保守性インデックス、循環複雑度、継承の深さ、クラスカップリング）で測定される開発パフォーマンス。C＃の場合は、Microsoft Visual Studioで取得します。テストカバレッジには、Ncover / Ndependが非常に便利です。開発バグの数によって測定されたテストパフォーマンス-最後の4つのスプリントによるロールオーバーシステムテストのバグによる最後の4つのスプリントのロールオーバー 配信された特定のリリース/機能で合格した自動化テストはありません。