バグレポートの方法

Qt のバグ追跡システムは昨年、Jira を用いた新しいものになりました。Qt Labs Blogs では "How to file a Qt bug report in the new bug tracker"  という記事でその使い方を説明していますが、ここにその日本語版を作成しました。元の英語記事が出てからシステムに変更された部分もありますので、そのままの訳ではありませんが参考にしてください。

Qt をよりよいものにしていくためにも、バグが見つかったら是非とも報告してください。よいバグレポートは Qt の品質を上げるよい助けとなります。なお、バグレポートは日本語では受け付けておりませんので、英語で行っていただく必要があります。

また、WebKit モジュールに関するバグは http://trac.webkit.org/wiki/QtWebKitBugs で報告してください。Qt の WebKit も webkit.org で開発しているため、そちらで対応を行っています。

バグレポートの流れ

  1. Qt Bug Tracker へGO!
  2. Screenshot of "Qt Bug Tracker"

  3. アカウントがなければアカウントを作成。すでにアカウントが作成済みならログイン。
  4. 右上の「Quick Search」欄や「Find Issues」を使って、同じバグがすでに報告されていないかを検索。
  5. 同じバグが見つかった場合、追加の情報をコメントしたり、「Vote for it」でそのバグに投票したり、「Watch it」で観察対象に指定したりしてください。
  6. レポート済みのバグが見つからなかった場合、「Create New Issue」からバグレポートを作成してください。
  7. バグのあるプロジェクトと報告の種類を選びます。選び終わったら「Next」をクリックしてください。
    Projects
    バグを報告するプロジェクト。通常は Qt や Qt Creator で見つかることが多いでしょう。
    Issue Type
    報告の種類。バグの場合には「Bug」を、機能の追加などの要望の場合には「Suggestion」を選択してください。そのほかの項目を選択する必要は通常ありません。

    Screenshot of "Create Issue - Qt Bug Tracker"

  8. 以下の項目を埋めます。
    Summary:
    一行でバグの内容を具体的に記載してください。
    Affects Version/s:
    バグが発生するプロダクトのバージョンを選択してください。
    Component/s:
    バブが存在するコンポーネントを選択してください。たとえば、フォントの扱いに問題がある場合は「Font handling」を選択してください。
    Description:
    バグの詳細を記載してください。バグの再現に必要な最小限かつ詳細な手順や、報告者と担当者との間でバグの相互理解を深めるためにも期待される結果とバグが発生したときの結果などを教えてください。また、Qt がクラッシュする場合にはスタックトレースも非常に有用な情報です。スタックトレースの取り方はプラットフォームに依存しますが、スタックトレースを記載する場合にはデバッグ情報を持っている Qt を使ってスタックトレースを作成してください。Qt を自分でコンパイルしている場合には configure のオプションに「-debug」をつけてビルドしてください。バイナリパッケージをインストールしている場合にはデバッグパッケージがあればそれをインストールしてください。また、バグの発生に条件がある場合などもここに記載してください。
    Environment
    OS、ウィンドウマネージャ、コンパイラなど、バグの再現に必要と思われる環境の情報を記述してください。
    Attachment
    バグ再現用のサンプルプログラムやスクリーンショット、スタックトレースなどがある場合には添付してください。サンプルプログラムを添付する場合にはバグの再現に必要最小限のコードになるようにしてください。
    Source Req ID
    空のままにしておいてください。
    Followed by
    どの項目もチェックせず、そのままにしておいてください。

    Screenshot of "Create Issue(details) - Qt Bug Tracker"

  9. 必要な項目を埋め終えたら「Create」をクリックしてバグの報告を終了します。

報告されたバグには、Troll(Qt チームの人間のことをこう呼びます)が優先順位の決定や修正のスケジュールなどをレポートに反映します。もし、バグを修正するパッチがあればマージリクエストを提出してください。よりスムーズにバグの修正ができるかもしれません。

最後に

バグレポートには可能な限り多くの情報を記載してください。また、バグが regression(以前のバージョンでは発生しなかったバグ)かどうかもわかれば記載してください。もし、以前のバージョンでは正しく動作していた場合、そのバージョンを教えてください。オートテスト用のサンプルがあれば将来そのバグが再度発生するのを防ぐことができます。

あなたがよいバグレポートをしたつもりでも、そのバグが再現できないことがあります。また、他の類似のバグと誤認してレポートを reject (拒否)することもあります。そういう場合にはコメントでバグの状況をより詳しく説明してください。

コミュニティや顧客の皆様からのバグレポートには大変感謝しております。バグの修正がすぐにできないこともあるかもしれませんが、皆様のフィードバックは非常に有用なものとなっております。バグを見つけたときには是非ご一報ください。よろしくお願いします。


Blog Topics:

Comments