Document Actions
|
||||
|
テスト容易性(EoT)」と「変更容易性(EoC)」を2つの鍵概念として、良い設計と
は何かを再定義しようとしている。今回は、テストの役割について再考する。
まず、テストとプロジェクト管理の話をしたい（テストとドキュメントの話、
テストとコミュニケーションの話、テストと開発リズムの話、などと続く予定）。 みなさんは、プロジェクト管理の進捗指標として何を使っているだろうか？ 「工程ごとに違うが、成果物の完成に対する到達度だ」という答えが一般的だ と思う。しかし、「設計書90％完成という報告が2週間続いている」というよう な進捗会議に参加したことがあるはずだ。私が考える進捗管理の基本は、
さて、本題のテストにもどる。筆者が提案する最もよい進捗管理の単位は、ア ジャイル開発で使われている、 「受け入れテストを通った顧客要求の数」 だ。テストは、0か1かのどちらかに倒れる。また、受け入れテストをパスした、 ということは顧客価値に直結する。顧客が求める仕様に対して受け入れテスト を定義し、これを通過した数で進捗を測ろう。 アジャイル開発では、要求をストーリーという顧客価値の単位に分割し、それ を「一個流し」する。そして、テストまで通過した要求の数で進捗を測る。全 体を見据えた大きな分析・設計に時間をかけずに、小さな要求単位をテストに まですばやく流す、ということを繰り返す。この手法は、優先度の高い要求か ら顧客に早いうちから供給することができるため、最初に全要求を固定する必 要がなく、都度の要求変化に強い。 ウォーターフォール型開発でも、テストで計測することは可能だ。「（弱い） 繰り返し型のプロセスを導入する」、「要求全体を分割して、少しでもいいか ら優先度の高い要求をテスト工程にまで早く流してしまう」などの工夫ができ る。また、テストで計測できなくても、「自分の工程の範囲内での顧客（誰が 自分の作業を待っている人）の価値で、計測する」ことによって、進捗管理の 改善ができるはずだ。 テストは目盛り付いたメジャーだといえる。 テストによって、進捗を推し量る(guess)のでなく、進捗を測る(measure）のだ。 |
||||
| つづき |