はじめに 
本記事の内容は万人にオススメするものではありません。
自己責任でお願いします。
前提として 🔽
テスト自動化をはじめるのは、とても楽しい。
そして ⏭️
そして、テスト自動化導入のために上司を説得するのも楽しい。
・・・。
いやいや 
んなわきゃねーよ。たのしくねー。 
というわけで 😅
テスト自動化は勝手にやることとした。
本題 
状況
- ユニットテストは自動化済だが、
- 受け入れテストは手動だった。
状況
そして、手動でテストをやるのはだるかった。
じゃ 
受け入れテストを自動化するか。
修羅の道 
この道を行けばどうなるものか。迷わず行けよ。 行けばわかるさ。
by アントニオ猪木
ハイ、地獄 
テスト自動化は 
結合度が上がるほど、テスト自動化の難易度が増す。
Why ?
なぜか
結合度が高いほどソフトウェアは不安定になるから。
なぜか
結合するほど、ミドルウェア、システム外要素などが複雑に絡みあっていく。
そもそも 
そもそも、受け入れテスト等の結合度の高いテストの環境は、環境を作ること自体の難易度が高いことも多い。
さらに
機能追加や不具合対応の受け入れテストの場合、テストシナリオはマニアックなものが多く、細かい操作が必要となるケースも多々ある。
だ～か～ら～
だから、仮に自動化できたとしてもテストシナリオの流用やテストスクリプトの再帰テストでの再利用はしにくい。
結局のところ
結局のところ、人間を用意して人海戦術でテストしたほうがコスパが良いこともある。
結論
上司を無視してテスト自動化に取り組んでも 
だけど、コスパの良い対象を選ぶことが大事。