テストフェーズ再考：目指せ！テスト無しでの納品

ソフトウェアの開発は大きく分けると次の工程に分類できます。

1. 要件定義
2. 設計
3. 実装
4. テスト

まぁ、細かく言えば、他にも色々と分類方法はありますが、基本はこんな感じです。

分かりやすく言えば、「何を作るかを決める」「どうやって作るかを決める」「実際に作る」「ちゃんと出来たか試す」ということです。

---

さて、
とあるソフトウェア開発において、クライアントがこんな条件を出してきました。

「1回目のテストでは、1000ステップ毎に、テスト失敗が1件」

ソフトウェアの規模を計るのにステップ数とか言い出すのも今時ナンセンスですが、それは、この際置いておきましょう。

ここでの肝は、クライアントは「テストに失敗しろ」と言っていることです。
それも、多くても少なくてもダメだという。

「バカじゃないの」と言いたくなりますが、真意は、こういう事なんですけどね。

テスト失敗件数が多いと、プログラマの能力が問題視され、全体の品質が疑われます。
テスト失敗件数が少ないと、テスト項目が不足している（適切ではない）と解釈され、全体の品質が疑われます。

まぁ、十分納得のいく理由です。

---

ですが、ちょっと待って欲しい。

これは「しっかりテストをして、潜んでいるバグを発見し、潰しましょう」という考えが根底にあってこその発想です。

当たり前のことですが、それを当たり前と考えたら話が進みません。

ここで声を大にして言いたい。

テストフェーズは、バグを見つける工程にあらず！

「おいおい。だったらテストは何するんだよ。バグはどこで潰すんだよ」

テストフェーズは、バグが“無い”事を確認する工程です。

大して変わらないかと思うかも知れませんが、バグが見つかった時の対応が大きく変わります。

テストがバグを見つけるための工程なら、テストでバグが見つかるのは喜ぶべきことです。目的が達成されたのですから。ミッションコンプリートです。
ところが
バグが無い事を確認する工程の場合では、それ以前の工程の方法論を見直すことになります。大いに反省しましょう。ミッションフェイルドです。

具体例を挙げると、
動的に確保したメモリの解放を忘れてメモリリークを起こしたことが分かったら、直して終わりとするか、
（見つけた問題は直した上で、次からは）生のポインタは使わず shared_ptr（みたいなもの）を利用しようと実装方法を変えてみるかの違いがあります。

バグは潰しません。「バグが入り込む余地」を潰します。
（もちろん見つけてしまったバグは潰しますよ）

---

と、まぁ色々と言ってきましたが、
現実問題として、「バグの無いプログラムは無い」と言われるように、ここでの話は理想論ではあるのですが……。
と言うか、プログラマとしての心構えですね。

目指せ！テスト無しでの納品（良い意味で）

あ、ユニットテスト等の自動テストは、実装フェーズの範疇です。

---

1000ステップで1件もテスト失敗なんかするわけがないので（タイプミスはコンパイラが見つけてくれるし、ロジックミスはユニットテストで粗方見つかってる）、エラーメッセージの誤字とかでテスト失敗件数を水増ししたのは秘密。