開発促進のテストと品質保証のテストは別物だった件
日本PostgreSQLユーザ会北海道支部 / Ruby札幌 合同セミナーを見て、TDD(テスト駆動開発)について思ったことをもう少し。
テストの分類（スライドの43ページ目）が個人的には衝撃的だった。
- Developer Testing（開発促進のためのテスト）
- Customer Testing（進捗管理のためのテスト）
- QA Testing（品質保証のためのテスト）
ウォーターフォール脳でアジャイル開発に手を出したときの落とし穴はここだったのかと膝を打った。それはもう何回も。
伝統的なスタイルの単体テストは３なんだよね。品質保証。で、アジャイル開発でいうところのテストファーストってやつは１のことだったわけだ。そりゃ噛み合わないはずですよ。
TDDのテストを書くトリガって、「基本的な要件だから」とか「このへんがちゃんと動くか不安だから」とかだと思うんだけど、品質管理屋の目で見るとそのやり方ではテストケースが漏れるんだよね。それってホワイトボックステストに比べてカバレッジのレベルはどうなのよ？とか、限界値テストちゃんとやってる？とか、あらゆるパターンの異常データ食わせてみた？とかそういう意味で。
それじゃあって言うんで、そのへんをしっかり網羅したテストケースを最初に書ききろうとして頑張ると、それはそれで開発効率が上がった気もしないし、そもそも楽しくもない。
自分なりに解釈してみると、Developer Testは「網羅性はあんまり気にせず開発促進に必要なものだけをやる」ということで良いのかな。異常系とかインタフェース周りとか開発が促進されないようであればやらなくていいよ、って。それでひととおりコードができあがったら、その後のフェーズとしてQA Testをしっかりやろうよ、テストケースはDeveloper Testでほとんどの項目がかぶってるかも知れないけど、不足分を追加でやろうよ、という感じ。
そんな風にやってみると旧態依然とした文化の開発会社でもTDDを取り入れやすいかもね。
ってなんで今回こんな文体になっちゃったんだろう。
