23. バグ票の書き方 その①
バグ票
JSTQBでは「インシデントレポート」と書かれている。
けどよく聞くのは「チケット」。
他に「バグレポート」だったり「バグ」だけだったり「BTS」なんてシステム名で呼ぶところも見てきた。
色んな名称があるが社内で通じる言葉にしておこう。
バグ票の主目的は以下。
- 関係者に、どんなバグが発生しているのか情報を提供する
- バグ登録から修正までのライフサイクルの管理
- テストプロセス改善のためのヒント提供
- バグ数や修正状況でシステムの品質や、進捗を追跡する手段を提供
たまに「新人さんでも書ける書ける」といった感じで、新人さんのバグ票を丸投げな人もいるが、わかりやすい文章を書くのは意外と難しい。
見ていると伝わらない表現が結構書かれていたりする。
あと、見ている限り、慣れてきた人ほど書き方が雑になる傾向があるように見えている（作者談）
毎日書いていることによって雑になってくるのだが、ちゃんと「読む人がいる」ことを意識しなければならない。
相手に伝わらなければレポートは意味をなさないのだ。
バグ票に現れる「正しくない」「不正である」「特定手順で」
テストケースのときにも書いたが、人によってとらえ方が様々あるような言葉は控えよう。
第三者が再現できるバグ票がベストな書き方である。
「正しくない」とはどう正しくないのか。
「不正である」とはどうダメだったのか。
「特定手順で」……自分の中に秘密手順を隠していても仕方ないので、しっかり明かしてあげよう。
あと「UI崩れ」。どう崩れているか書こう。
undefined
javascriptで初期化していない変数にアクセスするとこれがでるゾ！
