ここでいうバグ票とは、ユーザーやテスターから、メーカーないし、プログラマーに宛てて書く文章です。最近のITSだとチケットと呼ぶかもしれないモノです。
自分がいた会社では別の名前で呼ばれていたので正式な名称はとりあえず不明ですが、世間ではどうも良くこの名前を聞くので、仮に「バグ票」とします。
ここではこのバグ票において最低限書いておいた方が良いものを列挙します。テスターからプログラマー宛てにバグ票を書くとき、ユーザーから開発者にフィードバックするときなどにお使いください。
ただし自分も実戦から退いて長いので忘れてるところもあるかもしれないです。何かあればコメントください。
問題事象の概要
問題を一言で表す文章。チケットなら表題に相当。
たとえば「○○のアプリを起動中、フリックするとアプリが応答無しとなる」など。なるべく短く、かつ問題事象が大まかにわかる程度の内容が良い。
なお、基本的に「修正が盛り込まれない可能性があるもの」以外は「○○となる」「○○する」などの言い切り系で終わらせること。「○○について」などと曖昧な表現はしない。
条件
問題が発生する前提条件。たとえば「○○がインストールされていること」「○○が△△の状態であること」など、問題に関連しうる設定は全て列挙。
なお、なるべく箇条書き。
「なし」は最後の手段なのでなるべく書かない。
問題発生機種
パソコンならOSバージョン、搭載メモリ、CPU(ハードウェアに密接に関わりうる問題であれば加えてグラボ等のスペックも併記)、Webアプリなら使用しているブラウザ、スマートフォンなら機種など、問題が発生した機種、問題事象を確認した機種を列挙。
手順
問題発生に至る手順を、できるだけ入り口から書く。たとえば「アプリを起動してからの操作」だったり、「パソコンを起動してからの操作」だったり。この辺は問題事象の原因に推測がついてきたら大体分かると思います(パソコンの起動時間に関する問題なら、パソコン起動から書く等)。
なるべく箇条書き。問題事象で言及するため、番号付きで書いておいた方がいい。
条件とおなじく「なし」は最後の手段（とはいえ偶発的事象などはなしとかかざるをえない？）。
問題事象
手順〇にて△△が発生するなどといった具体的な問題事象。なるべく簡潔に、起こった事象のみを書く。
また、パソコンやアプリの再起動など、復帰操作があるのであればそれについても一緒に書く。
写真を添付できるなら、事象発生時のスクリーンショットなど掲載しておくと良い
同様の事象が何度もあった場合など、再発防止策を問う文言があっても良いけどそれはツラいしお互いの関係を悪くしかねないのでそこそこに。
事象発生後の動作
事象発生後、復帰操作(あれば)をするまでの間どのようになるのか、そしてそれによりユーザーが得るデメリットがあるかどうかについて、文章で書く。
問題と判断した根拠
この問題が「修正が必要な問題である」と判断した根拠。たとえばAndroidアプリなら、Androidアプリケーション開発デザインガイドライン( http://developer.android.com/design/index.html ) とか、RFCのドキュメント( http://www.ietf.org/rfc.html )とか、アプリの設計仕様書とか。
できるならその仕様書のどこ(章番号で指定)に違反するかなどを、引用を添えて書いておくといいかも。
また、違反しているだけだとちょっと弱い。もし可能なら「ユーザービリティを損なう恐れがある」とか「データの損失に繋がる可能性がある」など、想定しうるリスクについても言及しておくとよい
最悪「自分が仕様だ」でも良いけどあまりやると嫌われるぞ。
期待する正常動作
自分が期待する正常動作として、明確なものがあればなるべく書きましょう。もし書かないと最悪修正されないことがあります。
たとえば「○○が起きないこと」「ハングアップしないこと」「○○と表示されること」など。
問題事象の推定
もしこちらに推定が可能であった場合。
たぶんこのへんがおかしいのではないかと推定して書いてあげると開発者に喜ばれそうです。
たとえばログを見て「○○の設定値が間違っていると思われます」や「△△の動作について処理が漏れていると思われます」など、気付いた点があれば全部書いておく。
ただ、ユーザー→開発者ではそこまでやると疲れてしまうので、そこそこに。
再現性
再現可能な問題であれば再現性について書く
全体的に
とりあえず個人的には、この手のバグ票を送ってもし質問が来たりしたら、基本的にはこちらの落ち度だと思っています。
なのでこれだけにとらわれず、実際に運用してみて質問が来たらそれによってルールを補強する くらいが良いと思います。
また、気をつけておかないといけないのは、「自分の場で起きたことは、相手には全くわかってない」ということです。書いた後で第三者のつもりになって(あるいは第三者に直接)読んでみて、疑問点がないかどうか確認しておきましょう。
チェックリスト
なにかのチェックリストにコピペして使う用リスト。
- 問題事象の概要は書いたか
- 条件の記載は的確か
- 問題発生機種の記載は的確か
- 手順の記載は的確か
- 問題事象の記載は的確か
- 事象発生後の動作は記載したか
- 問題と判断した根拠は明確か
- 期待する正常動作は書いたか
- 問題事象の推定は書いたか
- 再現性は記載したか
- 第三者による(第三者がいない場合、第三者になったつもりで)チェックは済んだか