ページツリー
メタデータの末尾にスキップ
メタデータの先頭に移動

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

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

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

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

バグ報告と解決プロセス

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

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

バグ報告プロセスに従って進行するリクエストのワークフローは、Jira Service Desk と Jira Software とで同じです。ただし、バグ報告を処理するチームには大きな違いがあります。

Jira Service Desk を使用するエージェントのバグ プロセスJira Software で作業する開発者のバグ プロセス
  1. ユーザーが使用中のソフトウェアまたはサービスについて問題を報告します。
  2. サービス デスク エージェントは、既知の解決策をカスタマーに提供できるかどうか調べます。
    • 既知の解決策がある問題の場合、サービス デスク エージェントはカスタマーと共に問題の修正を図ります。
    • The problem may be new or the service desk agent can't find an answer from a knowledge base or development point of contact. In this case, the service desk agent escalates the bug report to the development team for fixing. Read more about escalating issues to other Jira teams.
  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. [フィールドの追加] を選択します。

Read more about adding custom fields.

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

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