bug-tracking - バグトラッカーのバグレポートの品質をどのように実施または維持しますか？

Question

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

ただし、実際には、報告されるバグの品質は大きく異なる可能性があります。それらは、オンライン（「機能Xが機能しない、修正してください！」）、機能要求、PEBKAC、または理解できない可能性があります。

バグトラッカーのバグレポートの品質をどのように実施または維持して、効果を維持しますか？

Answer 1

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

Answer 2

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

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

シナリオ：

予想された結果：

実績：

備考：

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

これらは、私が現在の職場で非常にうまく使用してきた慣行であり、ほとんどの作業環境に適合する非常に普遍的であると私は信じています.

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

それがあなたのチームであると仮定します: コメント フィールドで毎回使用される特定の構造を持つことができれば、それが入力されたときに期待されるものもあれば、それも良いでしょう。空白のフォームでその構造を定義できます。

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

特に、優先度の低いアイテムのバグ修正には時間がかかる可能性があり、人々は詳細を忘れがちです。

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

このトピックのすべてではありませんが、「質問の仕方」のような方法で、37 Signals ブログのこの投稿 -リンク テキスト

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

どんな製品？どのバージョンですか (写真で見つける方法を示しています)? プログラムを開いてボタンを押してログファイルを自動的に送信できるかどうか、それ以上の作業ができなくなったかどうか、変更が失われたかどうかなど、スクリーンダンプを含めると役立ちます。

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

Answer 6

エンドユーザーがバグや機能のリクエストを報告するには、UserVoiceなどを使用します。バグ トラッカー エントリは実際には内部にある必要があります。エンド ユーザーにとっては技術的すぎます。また、私見ですが、内部の仕組みが少し多すぎます。