設計におけるTDD-全てのアジャイル開発者へ- #swtestadvent2011
「Software Test ＆ Quality Advent Calendar 2011」 : ATND
テストと品質に関するAdventCalendarです。
やりたい！っていうことで、登録してみましたが、見習いテストエンジニアとしてはなかなか書くことがありませんでした。
ということで、僕が最近思いついたことを書きます。
「設計におけるTDDとは存在するのか？」です。
現在ではTDDは開発手法として大きく認知され、xUnit系やSpec系をはじめとした多くのテスティングフレームワークでプロダクトコードに対するテストコードを書いて、リファクタリングをつづけるというサイクルを行う事で早い段階で良質なコードを生み出すことに成功しています。
ではプロダクトコードの前の段階である設計ではどうなのでしょうか？
コーディングの前に設計することはたくさんあります。
フレームワークやインフラや言語の選定は必須と言えるでしょう。
またある程度のモデリングもするかもしれません。
また、顧客要件をストーリーや仕様として落とし込む事も考えられるでしょう。
これらにおいてもTDDが適用出来るなら有用なのではないでしょうか？
実は存在していたんです。
Wモデル
V字モデルが「要件定義<->システムテスト」「基本設計<->結合テスト」「詳細設計<->単体テスト」となっていることを踏まえて、Wモデルでは「要件定義時にシステムテスト仕様書の作成を行う」「基本設計時に。。。」とすすめていき、またそれぞれのテスト仕様書を時間経過とともにインクリメンタルに成長させていきます。
仕様検討時にテストからの視点を加える事で早期のリスク発見、見落とし、テスタビリティの確認、を行うことができ、仕様が洗練されます。
そして最初からテスト仕様書は完璧である必要はありません。これらは時間が進むにつれて、TBDが解決するに従って成長させていきます。
詳しくはこちらをご覧ください。
第18回 Ｗモデルに関する悩み相談 その１｜SQiP：Software Quality Profession
Wモデルは設計におけるTDD
そう、これってもうTDDですよね。現在の技術ではこれらが自動化されていないだけだと思います。
自動化できるテスティングフレームワークのないものをTDDと呼ぶ事については議論を呼びそうですが、この記事は「TDDにおけるサイクルと同じ概念ですよ」ってことが言いたいだけなので許してください。
で、プロセスがVモデルのようになっていなくともいいわけなので、つまり、コーディングに入る直前の仕様検討時にテストプロセスを組み込んでみましょう。ということです。
Wモデルに対する反論に対して
Wモデルについてたまに「仕様検討のプロセスが重くなって。。。」っていう意見を見ます。
ですが、それらは普通のTDDにおいてもそうなんですよね。「実装時のプロセスが重くなって。。。。」と一緒です。
でも、TDDは20%の時間が増えても、コードの品質があがることで後のテスト工数が50%減る。全体でのコストはダウンします。
Wモデルだって同じ事が言えるはずです。(自分が完全に導入できているわけじゃないので、断言できません。
