バグ報告のガイドライン
このガイドラインは Diego Ruizによって提供されています。 質問や改善案がありましたら、気軽に編集してください。
これは、コミュニティーに貢献可能なリストのひとつです。 コミュニティーへの貢献については IDempiereコミュニティーへの貢献を参照して下さい。
iDempiereでバグを発見したら
- バグがiDempiereのセキュリティ上の脆弱性である場合は、JIRAチケットを発行せず、脆弱性の報告方法のページを参照してください。
- JIRAのIssuesで検索して、バグがまだ報告されていないことを確認してください。 既に報告されているバグを発見した場合は、バグ報告に有益な情報を追加できるかどうかをチェックしてください。
- 問題に対処している未解決の課題が見つからない場合は、新しい課題を作成してください。チケットを作成する前に テストサーバ のいずれかでバグを再現できれば良いでしょう。
注意: 自分が経験していることと同じように思えるJIRAのチケットがクローズさている場合は、新しい問題を開き、新しい問題の本文に元の問題へのリンクを含めてください。
バグを報告する前に
- iDempiereの最新バージョンで問題が再現できるかどうかを確認してください。.
- よくある質問は FAQs on the forumを参照して下さい。
どうしたら良いバグレポートを提出する事ができますか？
バグはJIRA issuesで管理されます。
バグの内容と、そのバグが再現できるように再現方法の詳細な説明を記載してください。
- バグを特定するために、問題に対して明確でわかりやすいタイトルにして下さい。
- 問題を再現する正確な手順をできるだけ詳細に記述してください。
- 手順を示すための具体的な例を提示してください。可能であれば、Garden Wroldのデータで問題を再現してください。
- ステップを踏んだ後に観察した行動を記述し、その行動の具体的な問題点を指摘してください。
- 正しい挙動としてどのような挙動を期待しているのか、その理由を説明して下さい。
- 可能であれば、説明した手順に従っていることを示すスクリーンショットやビデオを含めて、問題を明確に示してください。
- iDempiereがクラッシュしたと報告している場合は、ログファイルからのスタックトレースを含めたクラッシュ報告を行ってください。
- 問題がパフォーマンスやメモリに関連している場合は、有効な数値を記載してください。
- 問題が特定の行動によって引き起こされたものではない場合は、問題が発生する前に何をしていたかを説明し、以下のガイドラインを使用してより多くの情報を共有してください。
下記の質問に答えることで、より多くの情報を提供してください。
- テストサイトで再現できますか?
- この問題は最近(iDempiereの新バージョンへのアップデート後など)から発生していたのでしょうか？
- 最近問題が発生し始めた場合、古いバージョンのiDempiereで問題を再現できますか？問題が発生していない最新バージョンは何ですか？
- 問題を確実に再現できますか？そうでない場合は、問題がどのくらいの頻度で発生し、どのような条件で通常発生するのかを詳細に記入してください。
バグ報告の構成要素
これらはバグ報告に含まれるべき理想的な要素です。あなたのバグが十分に報告され、明確に定義されていれば、コミュニティはそれを解決しようとし、それに取り組んでくれる可能性が高いでしょう。
- 具体的に ->例えば、XYZウィンドウを開き、新しいレコードを作成して、フィールドにName=ABC, Code=XYZ ...の値を入力しました。 など…
- より多くの情報を提供する -> 開発者が問題を再現するための情報を提供する場合は、少ないよりも多い方が良い
- 代名詞に気を付けて下さい。
- あなたが書いた文章を読み直して下さい。
- こちらのガイドを読んて下さい。
1. 要約 (バグのタイトル)
バグ報告の短い要約は、報告された問題が何であるかを理解するための最もわかりやすい方法です。これが第一印象であり、通常はバグレポートの全体的な品質に影響を与えます。
簡潔に、正確に、そして明瞭に (主語では簡潔に、説明では冗長に)。開発者は要約を読んで、"ああ、これがバグの原因だ "と言うことができるはずです。よくない要約は、"iDempiereが動作していません！"というものです。バグを探している人は、多くの場合、要約を検索していることを忘れないでください。良い印象を与えましょう: サマリーは、開発者にバグを調べるべきかどうかを伝えるべきです。
要約は短く、課題をいくつかのキーワードで記述する必要があります。
例示: 悪い例: '受注伝票明細に誤った価格が表示される'
この例では、問題の説明が不完全です。 価格が正しく表示されないのはなぜですか? 表示される前にどのようなアクションを実行しましたか?
良い例: 'プライスリストの価格が手動で更新した後も表示される'
2. 説明文での実際の結果を記述して下さい
実際の結果は説明文に記述する必要があり、特定のアクションを実行したときや実行後にアプリで遭遇した動作を表します。
実際の結果は、問題が多くの説明を必要としない場合、サマリーと同じにすることができます。
例示:
悪い例: 'お気に入りのウィンドウが表示されたままになっている'
この実際の結果の例では、問題に遭遇する前に実行されたアクションが記述されていないため、十分ではありません。 質問に答えてください。ウィンドウが表示されたままになっているのが問題なのはなぜですか？-> 以前に削除したからです。問題が発生する前に取られたアクションを含める必要があります。
良い例: 「お気に入り」セクションからウィンドウを削除しても、商品は「お気に入り」セクションに表示されます。
必要な項目をできるだけ具体的に記入することをお勧めします。
3. 説明文で期待する結果を記述して下さい
実際の結果は説明文に書いておく必要があります。メニュー項目をクリックしている場合、予想される動作は対応するウィンドウが開かれることです。
期待される結果の記述は、その行動そのものだけでなく、その行動に遭遇する前にとった行動を記述する必要があります。期待される結果フィールドが「Xのことは起こるべきではない」と指摘するだけのものでは十分ではありません。
例示:
悪い例: 'お気に入りのウィンドウが表示されない'
この期待される結果の例は、何が起こるかについての詳細を提供していないので、十分ではありません。 また、「なぜウィンドウが表示されなくなってはいけないのか」という質問にも答えなければなりません。
良い例: お気に入りからのウィンドウは削除しても表示されないはずです。
4. 説明文で再現方法･再現手順の記述をして下さい。
再現するための手順はバグ報告の重要な要素です。これらはメンテナやコミュニティのメンバーに、どのように問題を再現すべきかを指示します。 GardenWorldで再現可能であれば、コミュニティが問題を検証するのがはるかに簡単になります。
再現するための手順が明確でないと、開発者は問題を再現できず、却下されてしまいます。
- 再現するための手順は、遭遇した問題に至るまでに試験者が取った行動を完全に可視化する必要があります。
- 再現するためのステップは、1つのステップにつき1つのアクションだけを持つ必要があります。
- 再現するためのステップは、課題が明確になるように、ショートサマリーと同様のステップで終わらせる必要があります。
例示:
悪い例:
1. iDempiereを開き、ログインします。
2. 観察する
良い例:
1. iDempiereを開く
2. ログイン
3. ダッシュボードパネルが構成されたダッシュボードを表示するのではなく、空白で表示されていることを確認してください。
5. 添付資料
JIRA で報告したバグの証拠を提供することは非常に重要です。バグ報告、スクリーンショット、ビデオ、ログ報告に添付すると、メンテナが何が起こったのか、何が問題で、どのようにしてそこにたどり着いたのかを確認するのに役立ちます。
6. バグ報告の書式
iDempiere Version : <Copy from: About> Operating System (OS and version): Database (engine and version): Java version: Steps to reproduce 1. 2. 3. Expected results: Actual results? Please provide any additional information below. Attach a screenshot if possible.
