ユーザーに適切で有用なバグレポートを作成させる

誰もがユーザーに半ばまともな（読む：役に立つ）バグレポートを書かせる良い方法を知っていますか？

ほとんどのユーザーにとって意味のある（読みやすく、理解しやすい）ものの、開発者にも役立つ情報を提供したかったのです。

青いボタンをクリックしても機能しません！ああ、私はちょうど一週間の仕事を失った...それを機能させる。

そのままではあまり役に立ちません。

私はリストについて修正し始めましたが、同様の方法が既に存在するかどうか、皆さんに確認することを考えました。

ユーザーにまともで有用なバグレポートを作成させる最も効果的な方法は

1. オンラインでレポートを表示するには...
   ^{[システム]レポートをご利用いただきありがとうございます。リクエストのステータスはこちらで確認できます：...}
2. ... 割り当てられたエンジニアからの評価とコメントとともに...
   ^{[エンジニア]次の詳細が欠落しているため、リクエストは拒否されました：...}
3. ... レポートを編集/改善するオプションがあります。
   ^{[ユーザー]要求された詳細が追加されました。再評価してください：...}

私はそれが唯一の効果的な方法であると主張するまで行きます。

それに直面してみましょう、バグレポートを効果的に書くスキルは経験によってのみもたらされます。経験を積むことを学ぶ必要があります。学習には、練習、フィードバックの取得、改善が含まれます。

ユーザーが編集可能なオンラインバグレポートは、ユーザーに改善を教える最も効率的な方法です。

• ^{上記に代わる選択肢は、1）ユーザーとの対面学習セッションを手配することです（確かに、特に世界中に数千人のユーザーがいる場合）。または、2）電話で説明します（「225行目で書いたがらくたを見ることができたら...」）。ほかに何か？3）電子メールでああ、必ず「あなたは2ヶ月前に私たちを送信したメールに、あなたは何もない、電子メール、あなたはこの日、私たちに5通の電子メールを送信していること、それらの3つが対象ではなかった...述べた青いボタンクリック：再、見2つ目は、10Mbのスクリーンショットが添付されたものです...何？見つからないのですか？」}

私の意見では、より重要なのは、バグを使用して、ユーザーと連絡を取る際に意味のあるものを確立することです。バグレポートを作成して理解することはスキルです。私のアドバイスは、ユーザーが最初に連絡を取りやすくし、必要に応じてより価値のあるフィードバックを段階的に行うことです。

たとえば、ユーザーの電子メールを取得し、次のテキストを含むプレーンテキストフィールドに入力して完了させます。

"I did _____ , and expected ______ to happen, but ______ happened instead."

メールを受け取ったら、自動返信をしてダブルオプトを取得し、バグを送信したこと、受け取ったことを確認し、バグのフォローアップは問題ありません。

このトピックに関して、MozillaとSunからいくつかのアイデアを取り入れることを検討してください。

• バグ作成ガイドライン -Mozilla MDNの記事
• 適切なバグを書く方法 -Mozilla QMOの記事
• 役立つバグレポートの書き方 -Sun SDNの記事

特に（Mozillaの「適切なバグを書く方法」ページから）：

バグレポートの概要

概要：バグを60文字未満でどのように説明しますか？提案された解決策ではなく、バグレポートを迅速かつ一意に識別し、問題を説明する必要があります。

良い：「ファイルコピーダイアログをキャンセルするとファイルマネージャーがクラッシュする」

悪い：「ソフトウェアがクラッシュする」

悪い：「ブラウザは私のWebサイトで動作するはずです」

コンポーネント：ソフトウェアのどのサブパートに存在しますか？このフィールドは、バグレポートを提出するための要件です。「コンポーネント」という語をクリックすると、各コンポーネントの説明が表示されます。適切なものがない場合は、「一般」コンポーネントを強調表示します。

OS：どのオペレーティングシステム（OS）で見つけましたか？（例：Linux、Windows XP、Mac OS X）。例：「複数の種類のオペレーティングシステムでバグが発生することがわかっている場合は、「すべて」を選択します。OSがリストにない場合は、[その他]を選択します。

説明：以下を含む問題レポートの詳細：

- 概要：これは、要約のより詳細な修正再表示です。たとえば、「ページをドラッグして選択すると、NSGetFactory関数でMacビルドがクラッシュします」。

- ビルドID：これを見つけるには、ロケーションバーから「about：」ページに移動するか、MozQAのNightly Tester Tools拡張機能がある場合は、ツール|ツールに移動します。Nightly Tester Toolsをクリックし、ビルドIDの出力を含むオプションを選択します。「Mozilla / 5.0（Macintosh; U; Intel Mac OS X 10.5; en-US; rv：1.9.1b3）Gecko / 20090305 Firefox / 3.1b3」のようになります。

- 追加のビルドとプラットフォーム：バグが他のプラットフォーム（または該当する場合はブラウザー）で発生するかどうか。「Mozilla / 5.0（Macintosh; U; Intel Mac OS X 10.5; en-US; rv：1.9.1b3）Gecko / 20081107 Firefox / 3.1b2」では発生しません。

再現手順：バグを引き起こす最小化されたわかりやすい手順。必要な場合は、特別なセットアップ手順を必ず含めてください。この良い例は次のようになります。1）Webページを表示します。（デフォルトのサンプルページhttp://www.google.com/を使用しました ）。2）ページをドラッグして選択します。具体的には、マウスボタンを押したまま、ブラウザーのコンテンツ領域の任意のポイントからマウスポインターを下にドラッグして、ブラウザーのコンテンツ領域の下部に移動します。

実際の結果：上記の手順を実行した後のアプリケーションの動作。例：アプリケーションがクラッシュしました。

期待される結果：バグが存在しなかった場合、アプリケーションは何をすべきでした。たとえば、ウィンドウは下にスクロールするはずです。スクロールされたコンテンツを選択する必要があります。または、少なくとも、アプリケーションがクラッシュすることはありません。

Simon Tathamによるバグの効果的な報告方法があります。経験の浅いユーザーでも理解しやすいように、物事をうまく説明しています。ただし、デメリットはかなりの量のテキストであるということです。ユーザーに問題を報告しようとして説明することに失敗した場合、通常はすべてを読むように説得することはできません。

有用なレポートを期待するために、ユーザーに簡単に理解して質問に答えることができます。

たとえば、「このエラーの前に最後に行ったアクションは何ですか？」、「このエラーの直前に...しようとしましたか？」

「私のビデオドライバーは最新ではありません。グラフィックライブラリは古いグラフィックドライバーと互換性がない可能性があります。」のようなバグレポートを作成するユーザーはいません。

ユーザーベースは、作成したソフトウェアに問題があるエンドユーザーであると仮定します。

熟練したソフトウェアエンジニアやテストの専門家になることはユーザーの仕事ではありません。期待するべきではありません。ユーザーは、ソフトウェアが「正常に動作する」ことを当然期待する平均的な人々です。そうでない場合、彼らはあなたの注意を引くために気をつけていると思うことは何でも報告します。それを変更することはできません。専門家が行うと思われる種類の報告を主張しようとすると、バグ報告と顧客の損失につながります。意味がなく、私にとって価値のない役に立たない種類のフォーム。実際に動作するソフトウェアを見つけに行きます。」

すなわち、それは彼らの仕事ではありません.....

適切なバグレポートが必要な場合は、専門家を雇ってバグを見つけてください。ソフトウェア開発者として、顧客とのやり取りが面倒な場合は、できる人を雇ってください。