テスターが誰がより多くのバグをオープンするかを競うのは良いことですか？
私はソフトウェア開発者です。アナリストが作成したテストケースを追跡して実行するテスターのチームがありますが、探索的テストも実行します。テスターが誰がより多くのバグをオープンするかを競い合っているようで、私はバグレポートの品質が低下していることに気付きました。機能をテストし、ソフトウェアの操作に関連するバグを報告する代わりに、テスターは画面の機能強化、使いやすさ、または愚かなバグに関するバグを提出しています。
これはプロジェクトに適していますか？そうでない場合、どうすれば（ソフトウェア開発者として）テスト担当者のチームの考え方や態度を変えることができますか？
もう1つの問題は、期限が見積もられて変更できないためです。そのため、期限が近づくと、テスターはテストケースを完了するために急いでいるため、テストの品質が低下します。これにより、クライアントが受け取る最終的な製品に正当なバグが発生します。
OBS：この競争は会社の慣例ではありません！これは、主催者が主催するテスターのみのコンテストであり、賞品はありません。
彼らがほとんどのバグを見つけることからコンテストを作るのは良くないと思います。彼らの仕事はバグを見つけることであることは事実ですが、彼らの仕事は「mostバグを見つける」ことではありません。彼らの目標は、ほとんどを見つけることではなく、ソフトウェアの品質を向上させることです。より多くのバグを発見したことに対して報酬を与えることは、最高品質のコードではなく、コードのほとんどの行を書いたことに対してプログラマーに報酬を与えることとほぼ同じです。
それをゲームに変えることで、最も重大なバグを見つけるのではなく、多くの浅いバグを見つけることに集中するインセンティブが与えられます。編集で言及したように、これはまさに組織で起こっていることです。
彼らが見つけたバグは公正なゲームであり、すべてのバグを発見する必要があると主張することができます。ただし、チームのリソースが限られている可能性がある場合は、テスターに数時間または数日かけてシステムを深く調べてもらい、本当に大きなバグを見つけてもらうか、数時間または数日かけてアプリをスキップして誤植や小さなエラーを探しますか？ページ上のオブジェクトの配置のエラー？
会社が本当にそれを使ってゲームを作りたいのであれば、開発者にバグにポイントを追加する権限を与えます。 「愚かなバグ」はマイナスのポイントを獲得し、よく書かれたレポートでバグを見つけるのは難しいですが、複数のポイントを獲得します。これにより、インセンティブが「最も多くを見つける」から「仕事をするのに最高になる」ようになります。 ただし、これもお勧めできません。プログラマとQAアナリストが協力して、人為的に数値を埋め込むことができるためです。
結論：バグを見つけてゲームを作ってはいけません。組織内で良い仕事に報いる方法を見つけて、そのままにしておきます。ゲーミフィケーションは、目標を達成したことに対して人々に報酬を与えます。 QAアナリストが「最も多くのバグを見つける」という目標を持つのではなく、彼らの目標が「ソフトウェアの品質を改善する」ことを望んでいます。これら2つの目標は同じではありません。
私は他の答えには少し同意しません。テスターにとっての「バグの発見」は、開発者にとっての「コードの作成」のようなものです。生の量は無意味です。テスターの仕事は、存在するバグをできるだけ多く見つけることであり、ほとんどのバグを見つけることではありません。テスターAが10個のバグのうち5個を高品質コンポーネントで見つけ、テスターBが263個のバグのうち58個を低品質コンポーネントで見つけた場合、テスターAがより優れたテスターです。
開発者が特定の問題を解決するために最小限のコードを記述し、テスターが壊れた動作を正しく説明する最小限の数のレポートを記述したいとします。最も多くの欠陥を見つけるために競争することは、ほとんどのコード行を書くために競争することに似ています。システムをゲームに入れるのは簡単すぎて、役に立ちません。
テスターに競争させたい場合は、テスターが何をすべきかにより直接的に基づいている必要があります。これは、ソフトウェアが説明どおりに機能することを検証することです。そのため、最も受け入れられているテストケースを書ける人、あるいはさらに多くのコードをカバーする一連のテストケースを書ける人を競い合うかもしれません。
開発者の生産性のより良い尺度は、完了したタスクの数とタスクの複雑さの積です。テスターの生産性のより良い尺度は、実行されたテストケースの数とテストケースの複雑さの積です。バグを見つけるのではなく、それを最大化したい。
私の個人的な経験に基づくと、これは良いことではありません。ほとんどの場合、開発者は重複した、ばかげた、または完全に無効なバグを提出します。通常、これらの多くは、クォータを満たすためにテスターRushとして月/四半期の終わりに突然表示されます。これよりも悪い唯一のことは、コードで見つかったバグの数に基づいて開発者にもペナルティを課すことです。あなたのテストチームと開発チームはその時点でお互いに協力し合っており、一方が他方の見栄えを悪くすることなく成功することはできません。
ここでは、ユーザーに集中する必要があります。ユーザーは、テスト中にいくつのバグが提出されたかはわかりません。最終的にソフトウェアが機能する限り、20件のバグレポートを提出しても、20,000件を提出しても、ユーザーは気にしません。テスターを評価するためのより良い測定基準は、ユーザーによって報告されたがテスターによって合理的に捕らえられたはずのバグの数です。
ただし、これを追跡するのははるかに困難です。データベースクエリを実行して、特定のユーザーによって報告されたバグレポートの数を確認するのはかなり簡単です。これが、「バグ報告」メトリックが非常に多くの人によって使用される主な理由だと思います。
バグを見つけてゲームを作ることに問題はありません。あなたは人々をやる気にさせる方法を見つけました。これはいい。また、優先順位を伝えることができないことも明らかになった。コンテストを終了するのはもったいないでしょう。優先順位を修正する必要があります。
シンプルな採点システムを持つ実際のゲームはほとんどありません。なぜバグを狩る必要があるのですか？
単にバグの数でゲームを採点するのではなく、バグレポートの品質の指標を提供する必要があります。それから、コンテストはバグの数が少ないです。釣りコンテストのようになります。誰もが高い優先度のスコアを取得する大きなバグを見つけようとしています。バグレポートの品質をスコアの一部にします。開発者に、バグレポートの品質に関するフィードバックをテスターに提供してもらいます。
ゲームのバランスを微調整することは簡単な作業ではないので、これを正しく行うために時間を費やす準備をしてください。それはあなたの目標を明確に伝え、楽しいものでなければなりません。また、ビジネスニーズの変化に応じて調整できるものになります。
バグを見つけることは彼らの仕事です。それらが物事の効率を低下させない限り（たとえば、それらのいくつかをカバーするために1つではなく10のタイプミスのバグを開くことにより）、これは彼らがやっていることを正確に実行するように彼らを励ますので、マイナス面はあまり見えません。
これは、@ CandiedOrangeの answer の拡張です。
注目をより有用な目的に移すことから始めるには、非常に非公式で非公式なものを検討してください。たとえば、開発者はいくつかの小さなトークンとトロフィーを購入できます。
少なくとも1つの重大なバグが報告された毎日、テスターのデスクに「今日のバグ」トークンを残します。週に1度、より大きくより優れた「今週のバグ」トークンまたはトロフィーを提供する開発者の行列で式典を開催します。 「今月のバグ」トロフィーの配信を、おそらくケーキを使って、さらに劇的にします。各トークンまたはトロフィーには、テストでバグが見つかったことが開発者にとってなぜ良いことであると開発者が考えたのかを示す引用が付随しているはずです。引用のコピーは、テスター全員が読める場所に置く必要があります。
テスターは、最も多くのバグを見つけることから、最も多くのトロフィーとトークンを収集することに注意を向けることを期待しています。そのための最善の戦略は、引用を読み、テストへのどのアプローチが開発者が重要と考えるバグを引き出す可能性が高いかについて考えることです。
重要でないバグレポートは無視してください。すべて非公式で非公式なので、いつでもシャットダウンまたは変更される可能性があります。
これはプロジェクトに適していますか？
いいえ。あなたが指摘したように、必要な機能を対象としない低品質のレポートが生成され、テスターは問題を悪化させ、実際に「想定されている」作業を完了するためにスクランブルをかけることになります。 「すること。
そうでない場合、どうすれば（ソフトウェア開発者として）テスト担当者のチームの考え方や態度を変えることができますか？
プロジェクトマネージャーに問題を報告してください。彼らはこの種のものを彼らの仕事の一部であると考えるべきです。あなたのPMがそれに対処することを望まない、またはできない場合、あなたは自分の対処戦略を開発するのに一種の行き詰まりになっています。（これは別の質問になるでしょう）