QA部隊がいればシステムの質が上がる、担保できるらしい、ってんで募集かけてるのをちょいちょい見かけるんだけど、システム自体がボロボロなのをQA部隊が改善できるわけではないし、複雑度の上がってる昨今のWebサービスとか旧来のQAでカバーできるわけがないので、ぶっちゃけただの金食い虫のお荷物になります。
これはもう、明日の朝になったらまた朝日が昇ってきます、並に確実です。
なぜテスト駆動開発とか言われるようになったのか、理解されてないんですよ。
「あれだろ？ テストファーストとか言ってまずテスト書けってやつでしょ？ 書けるわけないじゃん」
みたいに反論することが「本当のことを知ってる俺ってすげーだろ？」みたいな脊髄反射系逆張リストに引っ張られないように。
「まずテスト書け」と言われるのは、「どうせ機能が完成したら次の新機能実装に取り掛かっちゃうだろ？ するとテスト書かないだろ？」だからだ。
テスト駆動開発、とかたいそうな名前がつけられてるけど、そもそも「実装は検証可能なように書かれなくてはならない」なぜなら検証できないから、という至極真っ当な理由から来ているのだ。
つまり、今から実装する機能について、どうすれば検証できるのか。しかも自動テストで、という観点で、設計しろ、ということだ。
一連の処理をどう検証するか。
そのための道具が、オブジェクト指向だったり、モジュール化だったり、クリーンアーキテクチャだったりするわけだ。
それに加えて、ネットワーク境界をどうテストするか。
ライブラリをつかっているなら、ごく薄い変換層を噛ませて、そこより内側をテストするとか、Dockerでサービス(DBとか)立てて実際に叩くとか、やり方はいくつかある。
それらのうち最適なやり方で自動テストするようにすればいい。
そして、障害が発生するなどしたらSREが作業するって、マシンの入れ替えとか無くなったクラウド時代、やること、やれること、ないでしょ？
処理が途中で止まった場合の「自動」復帰の仕方などは設計段階で織り込んでおかないと、今時のサービスで手作業で復帰とか二重遭難希望者ですか？ と思う。
システムの質/安定を担保するのは、設計です。
設計、実装の段階に、QA、SREの観点を前倒しに入れ込むのが、DevOpsです。