「テスト自動化」したいのか、「自動テスト化」したいのか

おひさしぶりです。アウトプットしなくなるとアウトプットしなくなるな、と思ったので、再開です。

追記(公開翌々日)

以下の私のブログ記事、末村さん(Autify)の2020年の登壇資料の内容の劣化コピーであることが判明しました。

speakerdeck.com

ぜひこちらの資料をお読みください。

はじめに

それなりにSETっぽいことをしてて、「テスト自動化してます！」みたいな記事を見にすることも増えました。でも、思うことがあるので、書きます。

時間がない方へ

「テスト自動化」は手動テストを文字通り自動化することが主眼
「自動テスト化」は自動化されたテストを用いつつ、テスト計画から自動化を考えること

おことわり

ここから先、「自動テスト」といった場合、自動化されたテストのことだけではなく自動で動かす仕組みなどの話も含まれるかもしれません。文脈で判断ください。あとE2Eテスト寄りです。整理されてないです。すみません！

それは「テスト自動化」なのか、「自動テスト化」なのか

「テスト自動化」、着手しやすいが難しい

「テスト自動化」はわかりやすいワードだと思います。テストを自動化すればテスト自動化です。ただ、テスト自動化は実は安定しづらい難しいものです。

個人的なイメージでは、電気自動車の自動運転で考えています。「テスト自動化」はロボットに人の代わりに運転させるようなもので、「自動テスト」は車自体が自律して運転するようなものだと思っています。

こう考えると、前者の方が細かく難しく複雑な制御が必要で、後者は数値的に制御できる&mockしやすい、というような感覚がわかると思います。

ということで、テスト自動化を行った時の不安定さは手動テストでは考える必要のなかった暗黙的な部分にあり、それを上手にいなさないといけないのが難しく辛いところです。

これすっごい疲弊します。「自分でやった方が早いいいいい」ってなります。

「自動テスト化」はプロセス自体の自動化を前提にする必要がある

車自体が自律して運転するためには、車自体のセンシングはもちろん、自動運転を周囲の環境・インフラが考慮する必要があります。

GPSによる測位
交通情報のリアルタイム提供
信号等へのビーコン埋め込み

「自動テスト化」の難しさは、テスト計画やプロセス・テスト実行環境のインフラから練り直さないと上手くいかない、ということになります。自動テストが実行されるトリガーやパイプラインを用意するとか、結果を適切にフィードバックできる仕組みを事前に作っておくとか、です。

さらに、場合によってはプロダクト自体の構造を見直すことも必要になります。例えば、自動E2Eテストを行えるようにしようとしたら、画面の構造自体の見直しが必要になることはままあります。大リファクタをするのが怖いなら、当面はカスタムデータ属性を入れる*1など、メタデータ埋め込みなども必要になります。

幸い、ソフトウェアであれば、都市計画よりは実現しやすいです。

じゃあどうするべきなのか

最初から「自動テスト化」を目指すべきか

プロダクトの性質(特に新規開発かどうか)にもよりますが、何もわからないうちから「自動テスト化」するのはやめた方がいいです。たぶん。

「人の操作を模擬する」ということを軽視すると、後で困ることになります。ユニットテストでいう「mock刺しまくってテストしたらmockのテストにしかならなかった」ようなことが起こります。したがって、あくまで極力実際のフローを模擬するということが必要です。そのために、まずは「テスト自動化」して何となく掴むことも必要かなと思っています。

何からやったらいいのか

(特にレガシーな)プロダクトにとりあえず入れて実績出しやすいのは、やはりE2E的なテストの自動化だと思います。画面ぽちぽちするのは時間がかかりますからね。人力で5分くらいのテストが1分で自動で終われば、それは十分効果があるといえます。

こだわりがなければ、とりあえずTypeScriptでPlaywrightを触っておけばいいと思います。ただし最初からMCPとかAgentsとかを触るのではなく、生のPageとかLocatorとかを触って操作→テストすべきです。実際の画面で生じるFlakinessをイヤというほど浴びておくのが後々重要です。「ここは画面遷移してすぐでFlakyになりやすい部分だから、文言の表示を待つようにしておこう」とか、「このinputとbuttonはdivで囲えばlabelで選択しやすくなる」とか、「だからPage Object Patternができたんだな」とか、何なら「この操作はAPIのrequestで模擬できる」とか、そういったtipsのようなものを感覚的に掴めば、後で便利です。