バグ票、きちんと書けていますか？

バグ票、きちんと書けていますか？
excelでもtracのチケットでもいいのだけれど、バグ票、きちんと書けていますか？「バグ票なんて書くことないよ」、と思っているといざいざって時に困ることになるのよ。

バグ票に何が起きたか
とある品質に大変うるさい顧客のプロジェクトに参加したとき、いろいろあってバグ票を一元管理することになりまして。バグ票のフォームを用意して、テスト工程のときに、エンジニアの方々に案内して、いざ書いてもらったら...。

何が起きているの？

どうするの？

日本語でOK

っまず、日本語がおかしい。中堅やベテランのエンジニアが多いのに！大変うるさい顧客だし、それは設計書レビューで体感しているはずなのに、それは喉元もと過ぎればや台風一過のごとく忘れたのだろうか？と思うくらいに。

二つ目は、事実と推測がごっちゃになっていて、何が事実で何が推測なのか全くわからない。
＃まぁ、はじめの数行読んで、差し戻しましたが。

ワタシの普通は、じゃあどうするの？まで書くようになっています。

項目	書いてほしいこと
起因	何をしたときにバグが発現したか
事象	何が起きたか	時系列に“事実”だけ
影響範囲	事象による影響を受けた機能
原因	その事象が起きた直接の原因	即解決できないなら書けない
対処	恒久対処　原因を恒久的に防止する策
対処	暫定対処　原因を一時的に防止する策	恒久対処が別途必要で、場合により暫定対処が恒久対処になるときがあるが経過観察が必要

このほか、トレースできるように諸々諸情報も書いてもらいます。
で、何ができないかというと、“てにをは”は棚に上げて、まず、“時系列”に“事実”を書くことができない。
“時系列”に書けないと何が困るかというと、バグ票が支離滅裂だからインタビューするにしても、順序立てて、説明できない。こちらは、理路整然と説明をきくことができないから根掘り葉掘り聞くことになって、時間が余計にとられる。そして本人も何が順序立てて起きたかわからっていないから、原因特定にたどり着くまでに時間がかかる。
言語化できないのだから、あとでデバッグするにしたって、ね。ところどころ忘れるわけです。いや、コード見れば、と思うでしょうけれど、なら、そのテストが複雑なテストだったら？とかも思うわけです。テストは、ユニットテスト、結合テスト、システムテスト、受け入れテストとあってそのテストの中で負荷テストやモンキーとかもシステムによってやるわけです。で、だんだん複雑になっていくテストの中で、ユニットテストごときで何が起きているのか押さえていないエンジニアに複雑化するテストのバグをどれだけ解析できるのか？ということです。
テストの期間は有限だし、バグが発生した機能によって、テスト自体止まることだってある。そうなると、一刻も早く障害解析して、兎に角暫定対処を求められる。そのとき、どうするのよ、って。

先のプロジェクトでは、結果、全件差し戻し。最後は全部インタビューして修正案を作って差し戻し。

バグ票が書けないのに障害報告書が書けるわけがない
テスト工程やバグのプロジェクトに与える影響度や本番での運用などで起きたとき、顧客に説明が必要になることがままあって、障害報告書を書かなければならないことになる。それこそ、その障害報告書は、一字一句気を使って、

事実に基づき、決して嘘は書かないが、品質で要求される必要以上の対処にならない

ように、書く必要がある。事実に基づいていなければ、顧客は馬鹿でないからその矛盾に気付くし、嘘もあれば、顧客の疑問に嘘で応えることで嘘を塗り重ね、自分の首を締める。

障害報告書はその体裁があるが、ベースとなる情報はバグ票だし、そこから報告者に合わせてアレンジする。
でね、中身はバグ票なのです。障害報告書を書くのはSEリーダかもしれないし、プロジェクトマネージャかもしれない。でもソースはバグ票。
だから、バグ票がきちんとかけていないと、障害報告書が書けないのです。