極力ユニットテストを書かずに品質を確保する方法

今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。
やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。
ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。
これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。
これまでは、「ユニットテストは、できるだけ書いたほうがいい」というのが一般的な見解でした(と思う)。でも、「そういわれても、ユニットテスト書くのも工数がかかるし」という人が多くて、ユニットテストが普及していないのも事実です。そういう人たちに対して、「ユニットテストを書いたほうが最終的にはコストが下がるんだ」と説明しても、あまり納得感はないでしょう。事実、ここ数年、「ユニットテスト工数がかかる」と思っている人と「ユニットテストを書いたほうが最終的にはコストが下がる」と思っている人の会話は平行線のままです。
このような状況を改善するために考えたのが、「Programming First Development」のなかで、バグったところ(とその周辺)のみユニットテストを書くという方法です。このやり方なら、ユニットテストを書く工数は、かなり減ります。そして、偏在しているバグを効率よくつぶすことができるのです。
また、最初にユーザに実際に動かしてもらっているので、開発者が、仕様を勘違いするという「仕様バグ」をほとんどなくすことができます。修正が大変なのは、「仕様バグ」です。実装バグは、後から見つかっても、直ぐに修正することができるでしょう。
和田さん、太田さん、会場のみなさんとどういうディスカッションができるのか、本当に楽しみです。