web-dev-qa-db-ja.com

ユーザーにまともで有用なバグレポートを書いてもらう

誰かがを使ってユーザーにある程度まともな書き込みをさせる良い方法を知っていますか（read：便利）バグレポート？

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

青いボタンをクリックしても機能しません！ああ、1週間の作業を失っただけです...機能させます。

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

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

client-relationsbug-report
32
Rook

ユーザーにきちんとした有用なバグレポートを書いてもらう最も効果的な方法は、

  1. 彼らが彼らのレポートを見られるようにするオンライン...
    [システム]ご報告ありがとうございます。リクエストのステータスは次の場所で確認できます：...
  2. ...評価および割り当てられたエンジニアからのコメントとともに...
    [エンジニア]次の詳細がないため、リクエストは拒否されました：...
  3. ...レポートを編集/改善するオプション付き。
    [ユーザー]リクエストされた詳細が追加されました。再評価してください：...

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

それに直面しよう、スキル バグレポートを効果的に作成する は、経験のみが伴います。経験を積むために学ぶ必要があります。学習には、練習、フィードバックの取得、改善が含まれます。

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

  • 上記の代替オプションは、1）ユーザーとの対面型の学習セッションを手配することです（確かに、特に世界中に何千ものセッションがある場合）。または2）それらを電話で説明します（「225行目で書き込んだがらくたしか見えなかったら、見て」...）。ほかに何か？ああ3）メールで、「2か月前に送ったメールで、あなたが言った...いいえ、このメールではなく、今日5通のメールを送信しました。そのうちの3通は件名でした：青いボタンのクリック、2番目のボタン（10Mbスクリーンショットが添付されているボタン）を見てください...何ですか？見つかりませんか？」
16
gnat

私の意見では、より重要なのは、バグを使用してユーザーとの継続的な連絡を意味のあるものにすることです。バグレポートを書いて理解することはスキルであり、私のアドバイスは、ユーザーが最初の連絡をできるだけ簡単にして、必要に応じてより多くの価値のフィードバックを段階的に行うことです。

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

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

メールを受け取ったら、自動返信を行い、彼らがバグを送信したことを確認するための二重選択を取得します。それを受け取ったら、バグのフォローアップは問題ありません。

27
blunders

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

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

バグレポートの概要

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

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

Bad：「ソフトウェアがクラッシュしました」

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

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

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

説明：以下を含む問題報告の詳細：

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

-ビルドID：これを見つけるには、ロケーションバーから「about：」ページに移動するか、MozQAのNightly Testerツール拡張機能がある場合は、[ツール]に移動します。 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）ページをドラッグして選択します。具体的には、マウスボタンを押したまま、マウスポインターをブラウザーのコンテンツ領域の任意の場所からブラウザーのコンテンツ領域の下部にドラッグします。

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

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

10
Brian Snow

わかりやすい質問と答えやすい質問をユーザーに提供して、役立つレポートを期待できます。

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

「私のビデオドライバは最新ではありません。グラフィックライブラリが古いグラフィックドライバと互換性がない可能性があります。

4
Mert Akcakaya

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

4
Wladimir Palant

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

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

つまり、彼らの仕事ではありません。

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

3
mattnz