いもろぐ

思い立ったら書いていくスタイルで

TDDとテスト自動化

今回はプログラムじゃない話を。

アクセルを踏むためのテストとブレーキを踏むためのテスト の記事を教えてもらったの読んだ感想を。

私もTDDは「開発」手法であって「品質保証」の手法ではないと思います。(品質保証が何なのか、品質保証と品質管理はどう違うのか、という話はありますが)

ですので、TDDのテストがすべてグリーンだからといって、ユーザーの手元で不具合が起こらない、とは言えないと思っていますし、そこまでTDDで求めてしまうと上記の記事にあるようにTDDで行うテストとしては重すぎるし開発スピードも落ちるんだろうなと。特にWebの世界じゃスピードってものすごく大事。時には品質より大事。

デベロップメントテストは開発者がアクセルを踏むためのテストで、品質管理のテストは開発者に適切にブレーキを踏ませるためのテストなんだから。

はいい表現だなと思いました。

私が「技術を使ったQA」として最初に目指している状態は「E2Eテストの自動化ができること」です。

これは「自動テスト」ではありますが、私がイメージしているのは「現在人間がやってるテストで、機械に置き換えられる部分を置き換えていく」ことです。目的はリグレッションテストとして、その後の追加改修の際にデグレがないことを手動で確認する手間を省く。

機械に置き換えられない部分もあるわけです。今読んでる(去年からまだ読んでる)テストから見えてくるグーグルのソフトウェア開発にも出てくるのですが、いくら自動化が進んでも「知的な探索テスト」は人間がやったほうがいい。

これは自動化するときのポイントである「操作、判定、報告」でいうところの、「判定」の部分において、人間ならではの曖昧さ(曖昧であっても困らない部分)をどこまで許容できるか、てところにも関わってきてると思います。

ということで、「開発者なら当たり前にTDDやってるよね」という風潮が広がっている気がしますが「QAなら当たり前にE2Eテストの自動化やってるよね」という流れに乗って行きたいです。(あ。自動化のプロと探索テストのプロが同じ人かどうかは考えてないです)