テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。

23. バグ票の書き方 その①

f:id:m_training:20170730212049p:plain

23. バグ票の書き方 その①

 バグ票

JSTQBでは「インシデントレポート」と書かれている。

けどよく聞くのは「チケット」。

他に「バグレポート」だったり「バグ」だけだったり「BTS」なんてシステム名で呼ぶところも見てきた。

色んな名称があるが社内で通じる言葉にしておこう。

 

バグ票の主目的は以下。

  • 関係者に、どんなバグが発生しているのか情報を提供する
  • バグ登録から修正までのライフサイクルの管理
  • テストプロセス改善のためのヒント提供
  • バグ数や修正状況でシステムの品質や、進捗を追跡する手段を提供

 

たまに「新人さんでも書ける書ける」といった感じで、新人さんのバグ票を丸投げな人もいるが、わかりやすい文章を書くのは意外と難しい。

見ていると伝わらない表現が結構書かれていたりする。

 

あと、見ている限り、慣れてきた人ほど書き方が雑になる傾向があるように見えている(作者談)

毎日書いていることによって雑になってくるのだが、ちゃんと「読む人がいる」ことを意識しなければならない。

相手に伝わらなければレポートは意味をなさないのだ。

 

バグ票に現れる「正しくない」「不正である」「特定手順で」

テストケースのときにも書いたが、人によってとらえ方が様々あるような言葉は控えよう。

第三者が再現できるバグ票がベストな書き方である。

 

「正しくない」とはどう正しくないのか。

「不正である」とはどうダメだったのか。

「特定手順で」……自分の中に秘密手順を隠していても仕方ないので、しっかり明かしてあげよう。

あと「UI崩れ」。どう崩れているか書こう。

 

undefined

javascriptで初期化していない変数にアクセスするとこれがでるゾ!