テストの役割=進捗管理＋設計戦略

「EoM=EoC+EoT」を鍵概念として、良い設計とは何か、よいプロセスとは何か、を再定義しようとしている。今回は、テストの役割について再考する。

テストは設計とプロセスの両方の基本単位だ。まず、テストと進捗管理の話をしたい（テストとドキュメントの話、テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。

みなさんは、進捗指標として何を使っているだろうか？「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だと思う。しかし、「設計書９０％完成という報告が２週間続いている」というような進捗会議に参加したことはない？　（きっとあるはずだ。）

ぼくが考える進捗管理の基本は、 

•   中間生産物で計測しない
•    明確に０か１かで判断できる計測単位である
•    顧客価値で計測する

の3点だ。先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了という判断もしにくい。特に、「誰も待っていない」設計書は顧客価値と結びつかない。（書いても読まれることのないドキュメントを、ぼくは、WOD=Write-Only-Documentと呼んでいる。)

さて、本題のテストにもどる。ぼくが提案する最もよい進捗管理の単位は、アジャイル開発で使われている、

　「受け入れテストを通った顧客要求の数」

だ。テストは、０か１かのどちらかに倒れる。また、受け入れテストをパスした、ということは顧客価値に直結する。顧客が求める仕様に対して受け入れテストを定義し、これを通過した数で進捗を計ろう。

アジャイル開発では、要求をストーリーという顧客価値の単位に分割し、それを「一個流し」する。そして、テストまで通過した要求の数で進捗を測る。全体を見据えた大きな分析・設計に時間をかけずに、小さな要求単位をテストにまですばやく流す、ということを繰り返す。この手法は、優先度の高い要求から顧客へ早いうちに供給することができるため、最初に全要求を固定する必要がなく、都度の要求変化に強い。

ウォーターフォール型開発でも、テストで計測することは可能だ。「（弱い）繰り返し型のプロセスを導入する」、「要求全体を分割して、少しでもいいから優先度の高い要求をテスト工程にまで早く流してしまう」などの工夫ができる。また、テストで計測できなくても、「自分の工程の範囲内での顧客（誰が自分の作業を待っている人）の価値で、計測する」ことによって、進捗管理の改善ができるはずだ。

今回は、テストが果たす、プロセス中の「進捗ユニット」としての役割を考察した。

今後言いたいことは、テストが、設計とプロセスの、両方の最重要ユニットなんだ、ということ。

※参考資料

t-wada（http://d.hatena.ne.jp/t-wada/）さんが、より明確に「テスト」という言葉のカバー範囲を、役割から説明しています。

• 「Test」という言葉について(PDF)
  http://www.ne.jp/asahi/t/wada/articles/Test_in_TDD.pdf

さらに、設計戦略としてのテストとリファクタリング、TDDについて、コードを「きたない/きれい」と「動作する/動作しない」の４象限上の軌跡としてうまく説明しています。

• リファクタリングとテストの関係(PDF)
  http://www.ne.jp/asahi/t/wada/articles/Refactoring_and_Test.pdf

これで、品質保障方面の人との食い違いがいくぶん避けられるかな。。。