テスト/テスター効率の良い尺度は何ですか？
QA組織としてのテスト効率の測定に関して、経営陣との話し合いに参加しようとしています。これの背後にある主な理由は、チームの半分が外部に委託されており、私たちのビジネスが私たちがどれほど効果的/効率的であるかのいくつかの指標を提供したいと思っているためです。 。
私はこの問題について私が見つけた意見のほとんどを少しつついて、コードの行、配信されたストーリーポイント、導入された欠陥など、開発者の効率を中心に展開しています。
しかし、テスターはどうですか？私たちのテストは主に要件に基づいており、手動、半自動、および自動テストの組み合わせです（すべてを自動化することに慣れていないためではなく、テストシステムで自動化できないものがあるためです）。
書かれたテストの数は役に立たず、見つかったバグの数が多いと、効率的なQAではなく、開発が不十分であることを示す指標になります。
自動化対策（コードカバレッジ、機能カバレッジ...）は良い場合がありますが、顧客（開発者がそれをやりたいと思っているより動作しません）。
顧客が問題に遭遇しなければ品質は良いので、QAチームとプロセスの有効性（効率ではない）の適切な尺度はQAによって発見されていない顧客によって発見されたバグの尺度）。
このメトリックの主な問題は、作業が完了してから意味のある数値が得られるようになるまでにかなりの遅延が生じる可能性があることです。
前回のジョブでQAを評価するために使用したいくつかの指標があります。
- 見つかったバグの数。私はこれが嫌いです。開発者にとっては「書かれたコードの行数」のようなものです。
- 生成された自動テストケースの数。
- 機能テストでカバーされたアプリケーション全体のパーセンテージ。
- ステージングと本番環境で見つかったバグの数。
結局、QAチームの仕事は、バグが実際に出回る前にバグを見つけることです。それらの指標は、実際にその目標を達成することに基づいている必要があります。テストケースのカバレッジが低く、自動テストの量が最小限であり、本番環境でバグの発生率が高い場合、それらはうまく機能していません。ただし、製品にヒットするずっと前にバグを発見した優れた実績があれば、メトリックはかなり高くなるはずです。
QAは2つの主要な指標で測定する必要があります。QAを超えてフィールドで検出されるバグの数はいくつですか。それらの重大度は何ですか？
Dev-completeよりもリリースに近い重大なバグを見つけるために、Ding QAができるかもしれません。 （機能ごとの）完了予定日までにテストを完了しない場合、Ding QAを実行できる場合があります。
結局のところ、契約スタッフを使用することによって得られる節約よりも、契約スタッフの有効性を測定するために多くのお金を費やすことになると思います...
私が働いている会社は、いくつかのQAメトリックを使用しています。
私が最も適切だと思うのは、コードカバレッジです。 [〜＃〜] emma [〜＃〜] のようなツールは、手動テストに加えて完全な自動テストを作成するので、うまく機能します。
何をするにせよ、テストの数に集中しないでください。 便利 1日あたりのLOCと同じくらいです。