カスタマーからの効果的なバグ レポートの収集

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

JIRA Software は、開発者による開発作業の計画、ビルド、出荷を支援する課題およびバグの追跡ツールです。JIRA Service Desk は、出荷されたソフトウェアに関するバグやフィードバックをカスタマーがチームに送信するための簡単な方法です。

ユーザーは最高の相棒です。ユーザーからのバグ報告は、以下のことに役立ちます。

  • 他のユーザーに同じ問題が発生する前に問題を解決する
  • QA または自動化されたテストをすり抜ける問題の調査や修正を行う
  • テストで優先しないプラットフォームからの問題を把握する
  • 品質とユーザー エクスペリエンスを重視していることをユーザーに示す

課題はソフトウェア開発のあらゆる部分で生じる可能性があり、コードに限ったことではありません。あなたが、設計者、ドキュメント ライター、プロダクト マネージャー、またはその他のチーム メンバーが JIRA で自分の作業を追跡するとして、その作業に関連したバグを直接そのチームにエスカレーションすることもできます。

バグ報告と解決プロセス

バグを再現し、解決するために必要な情報は様々です。しかし、バグ報告を収集するためのプロセスを標準化することはできます。

カスタマー サービス テンプレートは、特定のリクエストをバグ報告ワークフローに関連付けます。このワークフローは、バグ報告プロセスを補完します。ご利用のサービス デスクの出発点として使用することができます。

Requests that follow a bug report process have the same workflow in JIRA Service Desk and JIRA Software. But, the teams' processes for handling bug reports have significant differences.

JIRA Service Desk を使用するエージェントのバグ プロセスJIRA Software で作業する開発者のバグ プロセス
  1. ユーザーが使用中のソフトウェアまたはサービスについて問題を報告します。
  2. サービス デスク エージェントは、既知の解決策をカスタマーに提供できるかどうか調べます。
    • 既知の解決策がある問題の場合、サービス デスク エージェントはカスタマーと共に問題の修正を図ります。
    • 新規の問題や、サービス デスク エージェントがナレッジ ベースまたは開発窓口から回答を得られない問題が生じることもあります。その場合、サービス デスク エージェントはバグ報告を開発チームにエスカレーションして修正を依頼します。他の JIRA チームへの課題のエスカレーションについてはこちらをお読みください
  3. サービス デスク エージェントは、カスタマーと開発チーム間の橋渡し役として、バグの修正に必要な追加情報を収集します。開発チームの進捗状況について情報を共有します。
  4. サービス デスク エージェントは、問題が修正されたことをカスタマーと確認します。次に、エージェントはカスタマーのバグ報告を解決します。
  1. 開発チームはバグ報告を受け取ります。
  2. プロジェクト マネージャーはバグの優先順位を決定します。その後、課題を開発者に割り当てます。
  3. 開発者はバグを調査し、バグ報告を確認または拒否します。
  4. 開発者は問題を修正し、課題を QA テスターにトランジションします。
  5. テスターは修正された問題を検証し、チケットを解決します。次に、サービス デスク エージェントに修正が完了したことを通知します。修正がカスタマーに届けられる時期などの追加情報を提供する場合もあります。


カスタム フィールドを使用してユーザーからの特定の情報を収集する

Work with your development team and JIRA administrators to share a custom field set. Define what custom fields you want to collect to aid developers fixing bugs. Your JIRA administrator can maintain these fields in a single screen scheme. They can apply the scheme to both development and service desk projects. Read more about custom fields and screen schemes.

開発者にとって、バグの調査や修正における最大の障害は、不十分な情報といえます。開発者が使用する最も一般的な情報は次のとおりです。

  • 再現手順
  • 観察された動作と期待される動作
  • スクリーンショット

バグ報告に関連するアクションを分類、報告、または自動化するために他の情報を収集する必要がある場合もあります。例:

  • OS
  • VERSION (バージョン)
  • component
  • URL
  • ユーザー エージェント文字列

収集できる情報が多いほど問題の診断が容易になります。そして開発チームから感謝されます。

既定では、[バグ報告] リクエスト タイプには次のフィールドがあります。

  • 要約
  • 症状
  • 添付ファイル

事前に作成されたカスタム フィールドをリクエスト タイプに追加する手順:

  1. In your service desk project, select Project settings > Request types.
  2. [バグ報告] リクエスト タイプ項目で、[フィールドの編集] を選択します。
  3. [フィールドの追加] を選択します。

カスタム フィールドの追加については、こちらをお読みください

ポータルにバグ報告のフォームを作成するためのヒント

  • [バグ報告] リクエスト タイプには、ヘルプと説明を追加できます。問題ごとに別個にリクエストを作成して報告するようカスタマーに依頼します。これは、レポートや開発スプリントでバグを追跡する上で役立ちます。
  • 情報を求めるときは、平易な表現で質問します。たとえば、期待される動作を収集するためにフィールドを追加する場合、「どのような動作を期待していましたか。」などと質問します。
  • 時々、開発チームに状況を確認します。ソフトウェアのバグを潰すためにさらに必要な情報があるかどうか尋ねます。
  • 時々、JIRA 管理者に状況を確認します。リクエスト タイプで再現すべき画面に変更があるかどうかを尋ねます。
最終更新日 2018 年 5 月 18 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.