テスターが誰がより多くのバグを開くかを競うのは良いことですか？

私はソフトウェア開発者です。アナリストによって書かれたテストケースをフォローして実行するが、探索的テストも実行するテスターのチームがあります。テスターは誰がより多くのバグを開くかを競い合っているようで、バグレポートの質が低下していることに気づきました。機能のテストやソフトウェアの動作に関連するバグの報告の代わりに、テスターは画面の機能強化、使いやすさ、または愚かなバグに関するバグを提出しています。

これはプロジェクトに適していますか？そうでない場合、どうすれば（ソフトウェア開発者として）テスターチームの考え方や態度を変えようとすることができますか？

もう1つの問題は、期限が推定されて変更できないため、期限が近づくと、テスト担当者がテストケースを終了するためにスクランブルし、テストの品質が低下することです。これにより、クライアントが受け取った最終製品に正当なバグが発生します。

OBS：この競争は会社の慣行ではありません！それは彼らによって組織されたテスターだけの間の競争であり、賞はありません。

私は、彼らが最も多くのバグを見つけることからコンテストをするのは良いとは思いません。彼らの仕事がバグを見つけることであることは事実ですが、彼らの仕事は「ほとんどのバグを見つける」ことではありません。彼らの目標は、ほとんどを見つけることではなく、ソフトウェアの品質を向上させることです。より多くのバグを発見したことに対する報酬は、最高品質のコードではなく、ほとんどのコード行を書いたプログラマーに報酬を与えることとほぼ同じです。

それをゲームに変えると、最も重大なバグを見つけるのではなく、多くの浅いバグを見つけることに集中するインセンティブが与えられます。編集で言及したように、これはまさにあなたの組織で起こっていることです。

見つけたバグはすべて公正なゲームであり、すべてのバグを発見する必要があると主張することができます。ただし、チームのリソースが限られている可能性が高いことを考えると、テスターに​​数時間または数日間システムを深く調査して、本当に大きなバグを見つけようとするか、数時間または数日かけてアプリをスキップして誤植や小さなページ上のオブジェクトの配置にエラーがありますか？

会社が本当にゲームを作りたい場合は、開発者にバグにポイントを追加する権限を与えてください。「愚かなバグ」は否定的なポイントを獲得し、よく書かれた報告書でバグを見つけるのは難しく、複数のポイントを獲得します。これにより、インセンティブが「最も多くを見つける」から「自分の仕事をするのが最善」になります。ただし、プログラマとQAアナリストが協力して数字を人為的に埋めることができるため、これも推奨されません。

結論：バグを見つけることでゲームを作らないでください。良い仕事に報いるためにあなたの組織で方法を見つけて、それをそのままにしてください。ゲーミフィケーションは、目標を達成した人に報酬を与えます。QAアナリストに「ほとんどのバグを見つける」という目標を持たせたくなく、彼らの目標に「ソフトウェアの品質を向上させる」ことを望んでいます。これらの2つの目標は同じではありません。

私は他の答えに少し反対するつもりです。テスター向けの「バグの発見」は、開発者向けの「コードの作成」に少し似ています。生の量は無意味です。テスターの仕事は、できるだけ多くのバグを見つけることではなく、できるだけ多くのバグを見つけることです。テスターAが高品質コンポーネントで10個のバグのうち5個を見つけ、テスターBが低品質コンポーネントで263個のバグのうち58個を見つけた場合、テスターAがより良いテスターです。

特定の問題を解決するために開発者が最小限のコードを作成し、壊れた動作を正しく説明する最小限のレポートをテスト担当者が作成する必要があります。最も多くの欠陥を見つけるために競うことは、ほとんどのコード行を書くために競うことに似ています。システムをゲーミングに滑り込ませるのはあまりにも簡単です。

テスターに​​競争をしてもらいたい場合は、彼らがやろうとしていることにもっと直接基づくべきであり、それはソフトウェアが記述されているように動作することを検証することです。そのため、最も受け入れられているテストケースを誰が記述できるのか、さらには、ほとんどのコードをカバーするテストケースのセットを記述できるのかを競い合うでしょう。

開発者の生産性のより良い尺度は、完了したタスクの数とタスクの複雑さです。テスターの生産性のより良い尺度は、実行されるテストケースの数とテストケースの複雑さです。バグを発見するのではなく、それを最大化する必要があります。

私の個人的な経験からすると、これは良いことではありません。ほとんどの場合、開発者は重複、ばかげている、または完全に無効なバグを提出します。通常、これらの多くは、テスト担当者がクォータを満たすために急いでいるため、1か月/四半期の終わりに突然表示されます。これよりも悪いのは、コードで見つかったバグの数に基づいて開発者にもペナルティを科す場合です。その時点でテストチームと開発チームはお互いに協力しており、一方のチームは他のチームの見た目を悪くせずに成功することはできません。

ここでユーザーに焦点を当て続ける必要があります。ユーザーは、テスト中にいくつのバグが報告されたかわかりません。見たものは、通過したバグだけです。最終的に20個のバグレポートを提出するか、20,000個のバグレポートを提出するかは、ユーザーが受け取ったときにソフトウェアが機能する限り、ユーザーは気にしません。テスターを評価するためのより良いメトリックは、ユーザーによって報告されたバグのうち、テスターに​​よって合理的に検出されるはずのバグの数です。

ただし、これを追跡するのははるかに困難です。データベースクエリを実行して、特定の人によって報告されたバグレポートの数を確認するのは非常に簡単です。

バグを見つけることでゲームを作成しても何も問題はありません。あなたは人々をやる気にさせる方法を見つけました。これはいい。また、優先度を伝えることができないことも明らかになりました。コンテストの終了は無駄です。優先順位を修正する必要があります。

単純なスコアリングシステムを備えた実際のゲームはほとんどありません。なぜバグを捜すべきですか？

バグの数だけでゲームを採点するのではなく、バグレポートの品質の尺度を提供する必要があります。そうすれば、コンテストではバグの数が少なくなります。それは釣りコンテストのようなものになるでしょう。誰もが、高い優先度のスコアを獲得する大きなバグを見つけようとしています。バグレポートの品質をスコアの一部にします。開発者に、バグレポートの品質に関するフィードバックをテスターに​​提供してもらいます。

ゲームのバランスを微調整するのは簡単な作業ではないため、これを正しく行うために時間を費やす準備をしてください。それはあなたの目標を明確に伝え、楽しいものでなければなりません。また、ビジネスニーズの変化に合わせて調整することもできます。

バグを見つけることが彼らの仕事です。彼らが物事の効率を低下させない限り（例えば、それらのいくつかをカバーするために1つではなく10のタイプミスのバグを開くことによって）、これは彼らがしているはずのことを正確に行うことを彼らに奨励しているので、欠点はあまりありません。

これは@CandiedOrangeの答えを拡張したものです。

より有用な目的に注意を移すために始めるには、非常に非公式で非公式なものを検討してください。たとえば、開発者はいくつかの小さなトークンとトロフィーを購入できます。

少なくとも1つの重要なバグが報告された毎日、テスターの机に「今日のバグ」トークンを残します。1週間に1回、より大きくて優れた「今週のバグ」トークンまたはトロフィーを配布する開発者の行列で式典を開催します。おそらくケーキで、「今月のバグ」トロフィー配信をさらに劇的にします。各トークンまたはトロフィーには、開発者がテストでバグが見つかったことが良いことだと考えた理由を示す引用を添付する必要があります。引用のコピーは、テスターがすべて読むことができる場所に置く必要があります。

テスターが、最も多くのバグを見つけることから、最も多くのトロフィーとトークンを収集することに注意を向けることが期待されています。それを行うための彼らの最善の戦略は、引用を読み、テストへのアプローチが開発者が重要と考えるバグをもたらす可能性があるものについて考えることです。

重要でないバグレポートは単に無視してください。すべて非公式で非公式であるため、いつでもシャットダウンまたは変更できます。

これはプロジェクトに適していますか？

いいえ。あなたは、それが必要な機能を対象としていない低品質のレポートになり、テスターが最終的に問題を悪化させ、実際に「想定されている」作業を完了することに気づいたことを指摘しました「やっている。

そうでない場合、どうすれば（ソフトウェア開発者として）テスターチームの考え方や態度を変えようとすることができますか？

プロジェクトマネージャーで問題を提起します。彼らはこの種のことを自分の仕事の一部と考えるべきです。あなたのPMがそれを処理したくない、またはできない場合、あなたはあなた自身の対処戦略を開発しているように立ち往生しています。（これは別の質問になります）

このようになった場合、それがどのようになるか（または既にどのようになっているのか）を考えると、必ずしも品質が低下することはありません。私はそれが量対品質比を減少させると思うけれども。これが悪いことなのかどうかによります。場合によって異なります

画面の改善、使いやすさ、または愚かなバグに関するバグを報告する。

本当にしたくないものです。 テスターでこれが明らかな場合は、報告したくないことはしないで、それについて明確にするように伝えます。それらのレポートの1つが再び表示されたときに実行してください。

彼らが競争する理由は、おそらく仕事中に楽しい時間を過ごすためであり、おそらく彼らは悪い仕事をするつもりはないでしょう（これが悪いと考えられる場合）。