ソフトウェアテストの設計は、ソフトウェアサービスの設計と同じ

今日、「エンジニアが如何にテストに取り組むか」みたいな話を聞きに行ったけど、最初から最後まで何か違和感があった。

勿論テストケースがコケると色々面倒だし、サービスが続けば続くほどテストケースがメンテできなくなってくるけど、
本来、テストケースでエラーが出たときは「テストケースでエラーが出たおかげで、本番リリース前にデグレードが見つかって助かった」と喜ぶべきだし、それを踏まえれば、テストケースのNGが増えてくるのはそれだけサービスが成長してる証として喜んでも良いのではないのだろうか。

そう、「サービスで不具合が起きる事を予防する」のがテストであり、何故それが必要であるかと言えば、「不具合が起きた時のリスク・コストを軽減する」ためだ。

上記を踏まえると「その機能に不具合が起きた時にどれぐらいのリスク・コストがかかるか把握してない」エンジニアがいくらテストを書いてもメンテナンスする価値のあるテストは書けないのではないだろうか。

テストを作る人間、テスト工程を管理する人間がビジネスを理解してなければ、ロクに使われてない機能のためにテストケースのカバレッジを100%にするとか、本番でのバグが検知できない意味のないテストコードとか、無駄なコストや負債が増えるだけではないだろうか。

逆に、エンジニアが「ビジネスモデル」を理解していれば「ほんとうに必要なテスト」というのが自ずと定まってくるはずだ。
「このプロジェクトは仕様が全然定まらないからテストは書けないんだよ」というのは自分が関わってるサービスを真に理解してないエンジニアの言い訳ではないか。

そしてエンジニア以外のサービスに関わってる人達もテストに向き合う方が良いはずだ。ソフトウェア開発は製品と製品の製造ラインを同時につくるものだから、製品のリリースだけに目を向けて、テストを含めた製造ラインを見なければサービスの真のコストは把握できない。