本当に困るバグなんていつも予想もつかないところから出てくるじゃないですか。
あと設計自体のミスとかさ。

TDDをやったら自動的に品質が上がるわけではないのは
最近のGoogle Chromeが実証してしまっている。

開発者たちが明かすGoogle Chromeが目指すものとは｜【Tech総研】
http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002245

> Google Chromeでは、開発プロセスの改善はほぼすべて自動化されています。従来のソフトウェア開発では、
> 誰かが何かを書き、専任のテスト担当者がテストを行い、バグが見つかったら直し、というのを何度も繰り
> 返していたわけです。それによって、ソフトウェア品質を向上させていた。
> しかし、Google Chromeではそういうことはなく、あるコードを書いた人は、テストも同時に行わないと
> いけない。このとき、テストは自動化されているんです。ほかの人が別の機能を足したときも、自動的に
> テストが入るので、元のものに影響を与えるようなものは受け入れられない。

これで、「マウスホイールが効かん」というすげーバグが安定版に入り込んでるんだから世話ないわ。

Chrome 32 スクロールの問題 まとめ - Google プロダクト フォーラム
http://productforums.google.com/forum/#!topic/chrome-ja/I05Ixft9UF8

あと俺ゲーム系だしな。モジュール単位ではもちろんテスト書くが
マスターアップ直前まで仕様がコロコロ変わるし、ゲームシステムや3Dの挙動のテストなぞ書けんよｗ
人間のテスターから１発でスクリーンショットとログとメモリダンプ届くとかそういう効率化はするけどな。

で、テストができないならせめて静的型言語を使ったりコードの静的解析をかけようと
ここが動的言語大好きなウェブの連中がおそらく100年経っても理解できないであろうところだ。

ま、どんな技術や方法論にも適用範囲と限界があるよね。
テストを書かないのはまともなプログラマじゃないみたいな視野狭窄な言説を見かけると
鼻で笑っちゃいますね。