おそらく、急遽新人に不具合票の書き方を伝えないといけない気がするのでメモ書き。
もともと新人教育では一連のソフトウェア開発を教えるので、PMBOKに従い、
・要件定義
・設計（外部設計、内部設計、詳細設計、画面設計など）
・コーディング（単体テスト込み）
・結合テスト（不具合票の取り回し込み）
・システムテスト、運用テスト
・運用保守に関する手順書
あたりを網羅するようにしている。なにか、品質が悪くてどうしようもなくなっている場合は、初手として上記の PMBOK のプロセスが欠けていないか確認する。各プロセス自体は必須という訳ではないが、視点として落としてしまうとそこにハマるという特性がある。なので、俯瞰して網羅的に知っておいて損はない。知っているが、時間や予算の関係で「やらない」という選択肢を敢えてとるし、あるいは簡略化・省力化する。あるいは、うまくいかないときは原点に返って、組み込むことを考える。まあ、それが PMBOK のナレッジな処な訳だし。
不具合票の取り回し
不具合票は主に「結合試験」のような、複数名が関わっているときに必須となる。
・テスター
・コードを書いた人あるいは直す人
・設計書を書いた人あるいは仕様を解説できる人
３つの役割（設計→コーディング→テスト）はひとりで担ってもいいし、設計とコーディングがひとりでもいいのだが、そこそこの規模になるとこのプロセスは３分割されて少なくとも３名以上が関わってくる。
不具合であれ設計であれ、３者の中で情報をとりまわすのだから、なんらかのコミュニケーションが必要となる。伝わるならばメールでもいいし、口頭でもいいし、文書でもいい。
しかし、３者が同じ時間帯で働いているとは限らないし、不具合の直しがシーケンシャルになるとは限らない。むしろ、テストや直しは同時並行的に行われる。なので、不具合の情報をいったん取り回しができるように（居酒屋の伝票のようなものだ）しておくのが必要ある。
不具合票には、
・何か起こったか？
・いつ起こったか？
・再現するにはどうしたらいいか？
・どういう風に直せばよいのか？
が明確になるように記述する。
なので、不具合票には、
・テストをした人の名前（コードを直すときに現象を聞く相手）
・テストをしたときの日時（コードのバージョンが必要）
・何をしたら、どうなって、こうなったのか（再現性の手順、あるいは再現しにくいことを示す）
・現状と期待値を示す（現状の誤っている状態、そして期待する状態を明記する）
があればよい。これに加えて
・テスト仕様書の番号（あれば）
・不具合票の番号（問い合わせのときに便利なので）
・不具合票のタイトル（問い合わせのときに便利なので）
というものがあればよい。
最近は修正したコードを Git などで管理することが多いので、
・不具合票番号あるいは試験番号
・コードに書かれている試験番号、あるいはコミットするときの番号
を一致させておくと検索しやすくなる。
不具合票のフォーマット
平易なテキストでも構わないし、適当なスプレッドシートを使ってもよい。ただし、Excel の狭いセルだけで取りまわそうとすると、画面キャプチャや手順が書きづらくなるのでやめておいたほうがいい。現在では GitHub の isseus の活用が一番楽だが、まあ、そのほかのバグトラッカーをつかってもよい。
- 不具合票の番号
- 対応する試験の番号
- 不具合票のタイトル
- 試験をした人の名前
- 試験をした日時
- 試験対象のコード名（バージョンとか）
- 不具合の現象（動かないことを具体的に記述）
- 不具合の再現手順（箇条書きで記述）
- 期待される動き（試験項目へのリンクでもok）
- 合否判定
- 不具合を対処する人（だれが直すのかわからなくなるので。一般にコードを書いた開発者だが、テスターから開発者が見えない状況があるので注意が必要）
これに加えて
- コードを修正した人
- コードを修正した日時
- 再試験をした人（たいていは試験をした人）
- 再試験をした日時
を不具合票を直すときに記録をすればよい。
このあたりの手順は、車の修理とかパソコンの修理票とかを真似すればよい。
不具合票をカウントする
いわゆる、コードに中に含まれている不具合は複数の不具合票としてあらわれるかもしれない。また、対象の不具合を直さないと他の試験が進まないかもしれない。
この現象は、ワインバーグの言う「ブロッキング」に他ならない。
なので、不具合票がたくさん出たからといって品質が悪いとは限らない。不具合票に対処すればソフトウェアの品質は上がるわけだし、不具合票が０件だとしたら、潜在的な不具合があって見つからないのかもともとコードの品質がよかったのか（仕様や設計との齟齬も含めて）実はわからない。極端な話をすれば、テストを全くしなければ、不具合票は０件だし、不具合も出ない（見えないだけなのだが）のだ。
昔は、不具合票の数を指標として扱っていたものだが、「不具合票が多い」≠「コードの品質が悪い」とは限らないの注意が必要である。不具合票が残ったままであれば、コードの品質が悪いのは確かなことなのだが。
そういえば、富士通 Japan の時間 ID の件は全社展開（というか協力会社全社展開？）になったっぽいのだがどうなっただろうか？
何の目的でテストをするのか？
基本、テストプロセスはその前工程にあるプロセス（要求、設計、コーディング）をチェックするために行う訳で、対応としては
- 要件定義（Rquirement）に対する、システムテスト/運用テスト
- 設計（Design）に対する、結合テスト
- コーディング（Coding）に対する単体テスト
に分かれる。
一般的に再帰テストが行われるのが、コーディングと単体テストのワンセットで、これが XP のプラクティスのひとつになる。ただし、昨今はモックアップなどをつくることによって、設計をチェックするための結合テストも自動化を行うことも可能となっている。
他にユーザービリティテストやセキュリティテストがあるが、これが別のものと考えてよい。要件定義におて機能外要件としてユーザビリティ（Web APIの応答が何秒以内とか）を求めることもあれば、漠然と画面の色やパーツの配置を求める場合ので、それぞれのプロジェクトによる。
要件定義書が顧客の求める要件であり、設計書は要件定義をシステム的に満たすための設計（建築でいうところの設計図）になるので、視点の向きがことなる。
このため、所謂「不具合票」が目的とするところは、
- 要件を満たしているかを、システム的にチェックする
→ 要件が満たされない場合は、要件を満たせない設計になっている可能性が高いので、設計書を見直す - 設計を満たしたコーディングがされているか（詳細設計を含む）チェックする
→ 設計通りにできていない場合は、設計通りに直す
→ 設計通りに作ったとしても、「設計通りにはコーディングできない状況」、「設計が要件を満たしていない」場合もあるので注意が必要。 - コーディング自体のミスなので、コードを直せば不具合とはならない
という３つの分野に分かれる。
要件を満たすかどうかのシステム試験の場合、ウォーターフォール開発の場合は、この時点で不具合が発生してもなんともならないことが多い。そうならないように、適宜スパイラル開発か、アジャイル開発か、マイルストーンを使ったウォーターフォール開発に直す。ちなみに、富士通 Japan の ID 重複の件は、この部分に属する。要件を満たさない設計を作ってしまったか、要件そのものに「時刻を ID とする」と書かれていたか。肥大化する要件定義書を抱えている場合は、後者となることが多い。特に F の場合は。
自動化する単体試験においては、XP のプラクティスのようにテスト駆動をしてもよいし、コーディングをしながらテストをしてもよい。昔のように、コードをビルドしてリリースしなければ画面が動作しないということはないので、画面を動かしながら Web API の動作チェックも可能である。かつ、そのように設計とコーディングの順序を決めておけば、不要な不具合票の取り回しをしなくてもよい。労力が減る。Vue.js とかで画面を作っている場合は、常にエラーが出ない状態でコードを組む方がよい。かつ、その時々で画面の動作を画面設計書などと照らし合わせながらチェックをすれば、過大なテスト項目をこなさなくても済む。
システム試験と単体試験の間にある結合試験では、当然のことながら「単体試験である程度の品質を確保しておくこと」が重要になる。いわゆる、コードの品質が悪いと、結合試験の進捗度合いにもかかわるし、そこでブロッキングされてしまう。つまりは、ここに「Good Code ～」における「コードの品質」が関わってくる。コードが高品質か低品質かの前に、
- 結合試験をスムースに行えるだけのコードの品質が保たれているか？
という具体的な品質基準がここに出てくる。結合試験がスムースというのは、不具合がゼロというわけではない、設計ミスもあれば設計の読み違いもあるので不具合がゼロにはならない。ただし、そもそもコードが動いていないとか、コードを修正しようとしたときに誰かひとりに頼らないといけない（コメントがない、コードが読みづらい、コード分割され過ぎているなどなど）状況に陥るときは、明らかに「コードの品質が悪い」と言ってよいだろう。
というわけで、３つのテストプロセスにおいては、何の目的でテストを行っているのか？の違いを明確にしたうえで進めるのがよい。
