WebアプリケーションE2Eテスト自動化3つの壁

Slide 1

Slide 1 text

WebアプリケーションE2Eテスト⾃動化の3つの壁

Slide 2

Slide 2 text

⾃⼰紹介末村拓也(Takuya Suemura) ⽊村拓也じゃないよ QA / テスト⾃動化エンジニアというテスト⾃動化プラットフォームを作る会社で働いています

Slide 3

Slide 3 text

https://autify.com/ja/

Slide 4

Slide 4 text

E2Eテスト⾃動化してますか？

Slide 5

Slide 5 text

理想アサーションを⾃動化し、リグレッションの⾒落としを防げるようになる⾃動化により⾼頻度で実⾏できるようになる BDD・ATDDで振る舞いを保護しながら安⼼して開発が出来る

Slide 6

Slide 6 text

現実⾃動化は進んだものの…… バグを検知できない⼿動でやればたくさんバグが⾒つかるのに…… 思ったより⾼頻度で実⾏できない実⾏速度が遅いどうでもいいところでコケまくる不安定不安定不安定不安定「また落ちてるな、リリース後に調べよう」 →深刻な不具合

Slide 7

Slide 7 text

3つの壁バグ検出実⾏速度安定性これらを解決するための技術を広く浅く紹介してみます →深く話したい⼈は懇親会で！

Slide 8

Slide 8 text

バグ検出

Slide 9

Slide 9 text

E2E⾃動テストでバグを⾒つけるのは難しい網羅性が低い（網羅しようとするとテストケース数が膨⼤になってしまう）アサーションが無いところでバグが出がち「⼈がやってた時はバグを⾒つけられたのに……」

Slide 10

Slide 10 text

どうやってバグを⾒つけるか？基本的には「広く浅く」調べるようにするスナップショットテストビジュアルリグレッションテスト実⾏時エラーの検知

Slide 11

Slide 11 text

1. スナップショットテスト HTMLの差分を⽐較する⽅法引⽤元: https://jestjs.io/docs/en/snapshot-testing

Slide 12

Slide 12 text

2. ビジュアルリグレッションテストスクリーンショットを⽐較して差分を⽐較する⽅法 Original Current 引⽤元: https://codecept.io/visual/#using-resemble-helper

Slide 13

Slide 13 text

引⽤元: https://codecept.io/visual/#using-resemble-helper

Slide 14

Slide 14 text

3. 実⾏時エラーを検知するクライアントサイド(JavaScript)やサーバサイドのエラーを取得する⽅法 Sentryなどのサービスを使うとJavaScriptやサーバサイドのエラーをまとめて補⾜できる本番環境で使っているものをステージングやQA環境でも使うと良い TestCafe など、JavaScriptの実⾏時エラーを検知するとテストを中⽌する（失敗になる）フレームワークもある Seleniumはログ取得のためのAPIを廃⽌したっぽい、悲しい

Slide 15

Slide 15 text

実⾏速度

Slide 16

Slide 16 text

E2Eテストの実⾏速度を早めるのは難しい実ブラウザを使う以上重い仕事になる要素の表⽰待ちなど暗黙の「待ち」が多い実⾏環境によってはネットワークレイテンシが強烈

Slide 17

Slide 17 text

アプローチテストデータをAPIやコマンドで作る状態をキャッシュする並列実⾏

Slide 18

Slide 18 text

1. テストデータをAPIやコマンドで作るテストデータもE2Eで作ってませんか？画⾯ A, B, C がある B, Cのテストをする前にAを操作しないといけない Aが動かない場合B, Cのテストができない

Slide 19

Slide 19 text

1. テストデータをAPIやコマンドで作る APIを使うコマンドラインから任意のメソッドを実⾏する Railsでの例: bundle exec rails runner 任意のコマンド

Slide 20

Slide 20 text

1. テストデータをAPIやコマンドで作るフロントエンド→バックエンドの通信部分だけを実⾏する F12 → Network タブ → Copy as fetch

Slide 21

Slide 21 text

2. 状態をキャッシュする E2Eテストの実⾏はCookie, キャッシュなどが無いクリーンな環境で⾏うのが定⽯しかしログインなどの処理を毎回E2Eでやるのは⾟い⼀度ログインしSessionIDを保存しておけば後で使い回せる TestCafeにはUser Roleという機能があり、難しいことを考えずに↑のようなことが出来る

Slide 22

Slide 22 text

3. 並列実⾏複数のマシン (or ブラウザ) で並列に実⾏させる https://www.browserstack.com/guide/selenium-grid-tutorial

Slide 23

Slide 23 text

並列実⾏の注意点テストシナリオにべき等性を持たせる必要がある何度実⾏しても同じ結果になるようにするシナリオに順序を持たせてはいけない

Slide 24

Slide 24 text

コンテナによる並列実⾏環境を構築するためのOSS Chrome, FirefoxがインストールされたLinuxコンテナを必要に応じて⾃動で追加・削除してくれる Zalenium Selenoid 商⽤サービスあり

Slide 25

Slide 25 text

安定性

Slide 26

Slide 26 text

E2Eテストは不安定要素の表⽰待ち外部サービスのエラー通信環境

Slide 27

Slide 27 text

筋⾁リトライは全てを解決する

Slide 28

Slide 28 text

1. 失敗したステップをリトライする要素の表⽰を賢く待つよりも、リトライさせたほうが様々なケースに対応できるローディングスピナーが邪魔してクリックできない inputに⽂字⼊⼒できるようになるまでに時間がかかる URLが期待値に変わるまで時間がかかるステップのリトライ回数を設定できる場合は設定しておくと吉

Slide 29

Slide 29 text

2. 失敗したシナリオをリトライする外部サービスとの接続性などの問題で不安定になっている場合に有効規定の回数リトライし、⼀つでも成功すればOKとするステップと同様、デフォルトリトライ回数を設定しておくと楽

Slide 30

Slide 30 text

3. 不安定性を可視化する Allure Reporterでの例今までのテスト結果を全て保存しておき、失敗頻度が⾼いものにマークが付く

Slide 31

Slide 31 text

いかがでしたか？

Slide 32

Slide 32 text

E2Eテスト難しいこと多すぎ問題

Slide 33

Slide 33 text

そう、難しいんだ⾼レイヤーのテストになるほど時間とコストがかかる QAならみんな知ってるよね？ E2Eでやらなくてもいいことはたくさんあるまずは難しさを理解することが重要 E2Eでしか出来ないことに注⼒しよう

Slide 34

Slide 34 text

（余談）E2E = UIではないレンダリング + JavaScript実⾏の検証だけなら必ずしもE2Eである必要はないかもしれない Playwright はつい最近Microsoftから発表されたChromium, Firefox, Webkitのテストをするためのツール AppliToolsのUltrafast Gridは任意のページのDOMスナップショットを複数のブラウザでレンダリングし⽐較する UIテストが実機の縛りを抜け、E2Eテストの責務を減らし、シンプルに実現できるようになる

Slide 35

Slide 35 text

3つの壁バグ検出実⾏速度安定性

Slide 36

Slide 36 text

壁を乗り越えた先は⾼速・⾼頻度で実⾏されるテスト広範囲でバグを検出できるテスト安定動作するテスト