プログラマに優しいバグレポートの書き方

12,336 views

Published on

プログラマに優しいバグレポートの書き方

  1. 1. プログラマに優しいバグレポートの書き方 東京開発グループ リードソフトウェアエンジニア 牧野 克俊
  2. 2. バグとは?
  3. 3. コンピュータプログラムに含ま れる 誤りや不具合のこと
  4. 4. バグを修正するためには 何が必要?
  5. 5. プログラマがバグを再現する
  6. 6. そのためには?
  7. 7. 〜をしたら〜になった 「原因と結果」
  8. 8. バグレポート
  9. 9. 何を報告したらいいの?
  10. 10. • 分かりやすい要約• 前提条件• 時間・ユーザ(キャラクター)名• 起きた現象の詳細• 証拠• 詳しい再現手順• カテゴリ• 重要度・優先度
  11. 11. • 分かりやすい要約 –結論から記述し、理由や経緯を簡 潔にまとめる
  12. 12. • 前提条件 –アプリのバージョン –接続先サーバ –自分の環境• 時間・ユーザ(キャラクター)名 –サーバにあるログを特定するため の情報
  13. 13. • 起きた現象の詳細• 証拠 –画面のキャプチャー –ログ
  14. 14. • 再現手順 –同じことが複数の方法で可能なら ば、自分がとった方法を –あるならば回避方法
  15. 15. • カテゴリ• 重要度・優先度 –過大評価しない –頻度(=再現の手軽さ) –影響範囲(人数)
  16. 16. • オンラインゲームでは 進行不能 >= データ不整合 > サーバダウン > ルール > クライアントダウン > グラ フィック > 文言
  17. 17. プログラマの反応
  18. 18. 「いや問題でないよ」
  19. 19. 「いや問題でないよ」• プログラマの手元では動いている• 動かないのは環境や状況に違いが ある
  20. 20. 「いや問題でないよ」• なので、 –操作、手順に違いがないが –環境にどんな違いがあるか –勘違いしていないか
  21. 21. 「どうやって再現する の」
  22. 22. 「どうやって再現するの」• 操作を正確に伝える –手順 –対象• 勘違いに気をつける
  23. 23. 「もう起こせないの」
  24. 24. 「もう起こせないの」• 何かがおかしくなったら、ただち に何をするのもやめる• 可能なかぎり状況を保存した上で 再現確認
  25. 25. 「もう一回試してみて」
  26. 26. 「もう一回試してみて」• 面倒くさがらないで• 以前との違いに注意 –特にエラーメッセージの違い
  27. 27. その他諸注意
  28. 28. • すみやかに報告する• 既に報告されていても報告する–(正しい)情報は多いほどいい• 再現方法がわからなくてもとりあ えず報告する
  29. 29. • 推測は書かない –書くならば推測だと分かるように 書く• 問題を切り分ける• 要約以外は冗長なぐらいがいい
  30. 30. • 代名詞は避ける• 絶対に読みなおす –間違い・抜けがないか –何も知らない人から見て理解でき るか
  31. 31. • 仕様を調べる –期待した動作が間違っていないか

×