バグ トラッカーでバグ レポートの品質を強化または維持するにはどうすればよいですか?

Question

効果的なバグ追跡には、高品質のバグ レポートが不可欠です。理想的な世界では、すべてのバグ レポートには、影響を受けるソフトウェアのバージョンやバグの再現方法に関する段階的な説明などの重要な情報が含まれています。

ただし、実際には、報告されるバグの品質は大きく異なる場合があります。それらは、オンライン ライナー (「機能 X が機能しない、修正してください!」)、機能リクエスト、PEBKAC、または理解できないものである可能性があります。

バグ トラッカーでバグ レポートの品質を維持し、効果を維持するにはどうすればよいでしょうか?

Answer 1

私も Jon Limjap の意見に同意します。QA 担当者は、適切な基本的なトレーニングとガイドラインを前提として、適切なバグ レポートを投稿できる十分な能力を備えていなければなりません。それでも、より良いバグ報告を強制し、奨励する方法はあります。

• ほとんどのバグ追跡ソフトウェアには、バグ レポートの一部のフィールドを必須としてマークする方法があり、バグを正常に作成するには報告者が実際に適切な値を選択する必要があります。
• 通常、バグ レポートの基本テンプレートを次の行に含める可能性があります。

シナリオ：

予想された結果：

実績：

備考：

• 問題のあるマシン上で実行され、関連情報を収集してアーカイブ ファイルに圧縮する (場合によってはデスクトップに置く) バグ報告ツールを提供することができます (そうする必要があります)。次に、報告したいバグが発生した場合は必ずこのプログラムを実行し、バグにアーカイブを添付するようにスタッフに指示します。このツールは、関連性があるかどうかを考えずにバグに診断情報を添付できるように、使いやすく (実行可能ファイルを実行するだけで) 必要があります。このツールは通常、顧客に対しても非常に役立ちます。
• 最後になりましたが、「教育、教育、教育」です。人は経験から最もよく学びます。誰かが適切な情報を含まずにバグを開いたときは必ず、バグを扱う人がバグを開いた人に会いに行き、何が欠けているのか、なぜそれが重要なのかを説明するようにしてください。

これらは、私たちが現在の職場で非常にうまく活用している実践方法であり、ほとんどの作業環境に適合する非常に普遍的なものであると信じています。

Answer 2

私は以前、バグレポートの品質は同等だと思っていました。今でもそう思います…私が報告するバグには、QA や運用部門が入力したバグよりもはるかに有益な情報が含まれています。しかし、私は FogBugz のモデルを賞賛するようになりました。バグを入力するのは非常に簡単です。たとえサポート情報があまりなくても、エラー状態があることを知っているだけでも役に立ちます。さらに、ユーザーは何かが成し遂げられたように感じます。

Answer 3

トラッカーの使用法と各フィールドに必要なものについて、長すぎない優れたチュートリアルを作成します。他の人が行き詰まった場合に使用できる、汎用の参考例を作成します。

私は Docbook のマニュアル ページを編集するためのリファレンス コピーを持っており、これを繰り返し使用することで、構文のほとんどをすでに暗記しています。

Answer 4

これは、クローズド QA レビューについて話しているのか、パブリック ベータ版について話しているのかによって異なります。

パブリックベータ版の場合、ユーザーがバグリストを直接編集できるようにすることはお勧めできません。ユーザーのコメントとレポートを集約し、どれが実際のバグでどれが重複であるかを識別し、それらを再現する方法について何らかの手がかりを与える人を割り当てる必要があります。

ただし、これが正規の QA 担当者によって投稿されたバグ項目である場合は、従業員の能力に問題があります。バグを報告する方法、特にレプリケーションの手順を正しく行う場合には、適切なガイドラインを設定する必要があります。

Answer 5

厳しい質問。必要な特定のフィールドの入力を強制する方法がシステムにあるかどうかを確認し、致命的なバグが何らかの方法で目に入るようにして（電子メール、RSS）、すぐに攻撃できるようにしてみますが、ほとんどの場合、チームは品質基準を認識しており、それを遵守しており、ガイドラインは公開されて公開されています。

それがあなたのチームだと仮定すると、次のようになります。コメントフィールドに毎回使用される、入力時に期待される内容の特定の構造を用意できれば、それも良いでしょう。ソフトウェアにその構造を定義できるデフォルトのノートアウトラインがある場合はさらに良いでしょう。空白のフォーム。

ただし、ある程度は個人次第であり、それがコミュニケーション標準の一部であり、仕事の要件として期待されていること、そしてチームの他のメンバー全員に対して責任があることを認識する必要があります。なぜなら、他の人はそうすべきではないからです。回避できるとしても、さらなる詳細を調べるために彼らを追い詰める立場にはありません。

特に、優先度の低い項目のバグ修正には時間がかかる可能性があり、詳細を忘れてしまう可能性があるためです。

それがユーザーであると仮定すると、次のようになります。高度なことはできませんが、可能であれば、どのような形式であれ、人々が理解できる方法で質問するように努めます。

完全にこのトピックに関するものではありませんが、「質問の仕方」のような形で、37 Signals ブログのこの投稿は - リンクテキスト

たとえ、ユーザーに表示される質問をするための別のフォームが必要な場合でも、そのフォームはほとんどのデータをバグ プログラムにフィードするだけですが、私は正しい質問をするためだけにそうします。

どの製品ですか？バージョンは何ですか (写真で見つけ方を示しています)?プログラムを開いてボタンを押してログ ファイルを自動的に送信できれば、それ以降の作業が停止されたかどうか、変更内容が失われたかどうかなど、画面ダンプを含めると便利です。

ユーザーにとっては、おそらく質問の仕方が重要であり、特定の質問に回答する必要があること、またはどの質問がより役立つと思われるかを知らせることで、おそらくより良い回答が得られるでしょう。

Answer 6

次のようなものを使用してください ユーザーの声 エンドユーザーがバグや機能リクエストを報告できるようにします。バグ トラッカーのエントリは、本来は内部のものであるべきです。エンドユーザーにとっては技術的すぎる上に、私の意見では、内部の仕組みが少し公開されすぎます。