テスト駆動開発と品質

テスト駆動開発だと、外付けのユニットテストを書くためにインタフェースを意識して考えることになる。これによる設計の質の向上がある。また、ユニットテストで仕様を縛るので、不用意に仕様を変更してしまうことによるトラブルも減るだろう。また、テストを少し、コードを少し、で進めるならば、そこそこカバレージも確保できるので単純な（動かせばすぐ分かるような）バグも少ないだろう。
と、テスト駆動開発だと品質がよくなりそうな理由はいくつか思いつくのだけれど、でもテスト駆動開発はやはりテストではないな、と思うようになった（やっと）。
ユニットテストやそのフレームワークはテストに使えなくないけれども、それ自体が品質保証ではない。そもそも品質保証というのは、適応的な大きな活動のことだよね？ユニットテストしながらコード書くとかそういうこととは次元が違う。
ところで、従来の開発方式（沢山コーディングしてから、まとめて手作業デバッグという進め方）も結構問題の根が深くて、そのデバッグの結果品質はどこまで確保できたと言えるのか、よく見えない。見えないから不安だし、ごまかしたりもできるし、問題が複雑になる。インスペクションは上手くできれば有効だけど、保証と言えるレベルをキープすることは簡単じゃないしね。テスト駆動の場合なら、ユニットテストが残っていることで、はっきりと可視化できるものがある。それをいかに有効に使って品質を確保するか、だと思う。