#ビジネス分野を限定しないで話をするために、システム構築の現場という面に足をつけて話をしたい。
#※つまり、業務面からのテストというのはここではスコープ対象外とするってこと。
テストって何？
きっと側面が二つある。
一つは大概が請負契約で瑕疵担保を追求されるからちゃんと検証しておこうという受注側の側面。
もう一つはリリースして誰かが実際にそのシステムを使うことにより、ビジネスに負の影響を与えないために検証しておこうという発注側の側面。
ここでは前者の側面について話をしたい。
さて、テストって一言でいうけれど、いろんな工程がある。
UT、IT、ST...UAT...etc
じゃぁどの工程が一番重要か。
これは滝に限らず、上流に寄ったところでとめるのが当然一番。
だから、上記の工程ならUTが正解。
ただ、本当はコーディングの前にも正しく仕様書がないといけないから、設計書レビュー時も正解。
もっと言えば、要件を引き出すときに引き出せてないといけないから要件定義時も正解。
答えはなくて、すべての工程でパーフェクトであるのが理想。そう、あくまで理想。
でも、実際はその工程にならないことわからないこともたくさんある。
受注側、すなわち作り手側から言えば、現実にはUTでどれだけバグを作り込まないかが以降の幸せを左右する。
そんなときに出てきた一つがTDDという考え方じゃないかなと僕は思う。
でも、TDDで品質を保証するのは結構大変なのだ。
そのTDDで作ったテストケースは本当に網羅性があるの？
あなたはそこにはアルファベットしか入らないと思ってない？
だれかが「I（ローマ数字の1ね）」を入れられたらどうなる？
大切なのは、手法とかそれ以前に「UTとは○○をすることである」という共通認識。
それが体系化されて、プロジェクトとして、あるいは会社としてちゃーんと認知された中でテストをすることがとっても重要。
あなたのテストは本当にテストですか？
