『スタディサプリ』チームにおけるE2E自動テスト導入の進め方

2023/6/14 Autifyセミナー
チームで高速リリースを叶えるテスト戦略と自動化の実践
https://autifyjapan.connpass.com/event/285722/

オープニングプレゼンテーション

Transcript

1. 『スタディサプリ』チームにおけるE2E自動テスト導入の進め方 株式会社リクルート 2023/06/14 オープニングプレゼンテーション
2. 2 自己紹介 本名: 井上 達斗(いのうえ たつと) Twitter/Slack名: testtatto 経歴: • 派遣でテスト実施の仕事をし始めたのがテストエンジニアの始まり • ベリサーブでプロジェクト型の案件に従事 • リクルート(元Quipper)では1人目のQAエンジニアとして、チームの 立ち上げやE2E自動テストの導入、文化作りを行っている
3. 前置き • 話すこと ◦ テスト自動化ツールを導入するまでの一連のフロー ▪ なぜSeleniumを選ばなかったのか～AutifyとMagicPodを選びました～ で書いたことの発表用です • 話さないこと ◦ リリース高速化のための技術的なノウハウ ◦ Autifyの機能・使い方 3
4. 4 Outline 1. 自己紹介 2. 『スタディサプリ』における課題 3. 課題解決のためのプロセス 4. まとめ 5. (おまけ)E2Eテスト自動化ツール調査と選定基準
5. 5 Outline 1. 自己紹介 2. 『スタディサプリ』における課題 3. 課題解決のためのプロセス 4. まとめ 5. (おまけ)E2Eテスト自動化ツール調査と選定基準
6. スタディサプリについて 6 ※サービスとしてはモバイルアプリ (iOS/Android)もありますが、今日話す 対象はブラウザのみのスコープです
7. リリース作業 • 1週間に1回のリリース ◦ 決まった曜日にリグレッションテストとリリース • リグレッションテストはテストベンダーによる手動テスト • クロスブラウザで実施する ◦ Chrome ◦ IE(導入検討時はサポート対象) ◦ Safari ◦ Android/iOSのデフォルトブラウザ • 実施にかかる時間は複数人で1日半程度 7
8. 課題 • 1週間に1回のリリース ◦ 決まった曜日にリグレッションテストとリリース • リグレッションテストはテストベンダーによる手動テスト • クロスブラウザで実施する ◦ Chrome ◦ IE(導入検討時はサポート対象) ◦ Safari ◦ Android/iOSのデフォルトブラウザ • 実施にかかる時間は複数人で1日半程度 8 ⇒リリースサイクルをもっと早くしたい場合にリグレッ ションテストがボトルネックになってしまう
9. なぜリリースサイクルを早めたいのか？ 価値あるものを早く届けるため 9 計画 開発 価値の 提供 仮説・検証
10. 10 よし、じゃあテスト自動化だ！ ツールを使って高速化！コストカットだ！
12. 12 トライアルや、”やっていき”の精神は大事だが、テスト 自動化ありきで課題解決を考えるのは やめましょう テスト自動化の失敗プロジェクトは90%を超えているらしい(噂です) いくらツールが便利でも、大変さはある
13. 13 Outline 1. 自己紹介 2. 『スタディサプリ』における課題 3. 課題解決のためのプロセス 4. まとめ 5. (おまけ)E2Eテスト自動化ツール調査と選定基準
14. 課題に対してのアプローチ • 以下のようなアプローチを考えた ◦ コストをかけてテストベンダーの実施人数を増やす ◦ クロスブラウザの対象を減らす ◦ リグレッションテストのテスト項目を減らす ◦ 別のテストレベル(Unit Test, Integration Test)で品質を 担保する など 14
15. 課題に対してのアプローチ • 以下のようなアプローチを考えた ◦ コストをかけてテストベンダーの実施人数を増やす ◦ クロスブラウザの対象を減らす ◦ リグレッションテストのテスト項目を減らす ◦ 別のテストレベル(Unit Test, Integration Test)で品質を 担保する 15 上記アプローチを検討/実施した上で、 E2Eテスト自動化が必要という結論になった
16. ツール導入までの流れ 16
17. 組織の合意 一瞬で合意取れたので、割愛 17
18. 目的の明確化 E2Eテスト自動化で実現したいこと • 最優先(MUST) ◦ 高速リリースサイクル(日次)が実現できる ◦ リリースサイクルとは独立してリグレッションテストを実行できる • なるべく実現したい ◦ 手動のリグレッションテストのコスト削減 • できると嬉しい ◦ ビジネス側の人でもテストに関われる 18
19. ツール要件の整理 優先度順に高い順に整理した 1. CI/CDに組み込める 2. IE対応 3. モバイルアプリも同じツールでテストできる 4. 開発環境の認証を回避できる(セキュリティ要件をカバーした上で) 5. メンテナンスコストが低い 6. 開発者も取り組めるように学習コストが低いものが好ましい(将来的にはビジネス 側も) 19 ※なぜこの要件があるのかと優先度の付け方については 時間の都合で割愛
20. ツールの調査 初期候補としては以下 • Selenium webDriver + Appium • Cypress • Autify • MagicPod • Mabl 20 ※ツール比較については後述
21. コスト(費用)の見積 有償ツールであれば、担当者に詳細を聞く • 初期コスト • ランニングコスト • 今後追加で増え得るコスト コストの洗い出し後に、見積を行い、組織の予算内に収まっているを 確認する 21
22. フィジビリ 検討しているツールの中を実際にチームの中で運用してみた パイロットプロジェクト選びのポイント • 大きすぎないチーム(または機能) • リリースがある • コミュニケーションが取りやすい 22 その際の開発者のブログ Autify を導入したらなかなか良かった話 パイロットプロジェクト選びはかなり重要！！
23. ツールの決定 運用できそうな実感が得られたので、ツールを決定した！ 23 このときやればよかったこととして、ADR(Architecture Decision Records)をすぐに 残しておくと、そのとき考えたことが残るので、今後変更を検討した際に役立ちそう です。
24. Autifyのどういった部分が我々にささったのか？ • Autifyの学習コストの低さ ◦ QAエンジニアが少ない以上、E2E自動テストの運用を開発者 もやることになるので、魅力的だった • メンテナンス性の高さ ◦ 我々のフロントエンドではcssクラス名をランダム生成している が、self-healingによってその点については基本メンテナンス 不要になる • 環境構築の楽さ ◦ 専用の設定をしなくてもテストプラン内は並列実行される ◦ ライブラリなどのアップデートを自分でしなくてよい 24
25. 25 Outline 1. 自己紹介 2. 『スタディサプリ』における課題 3. 課題解決のためのプロセス 4. まとめ 5. (おまけ)E2Eテスト自動化ツール調査と選定基準
26. まとめ • テスト自動化の前に何かできそうな課題解決方法があればまずは そっちから • 我々の組織では自動化ツール導入をこういったプロセスで進めた ◦ 特にパイロットプロジェクトは大事 26
27. 27 Outline 1. 自己紹介 2. 『スタディサプリ』における課題 3. 課題解決のためのプロセス 4. まとめ 5. (おまけ)E2Eテスト自動化ツール調査と選定基準
28. おことわり 自動テストツール検討当時の情報からアップデートできていないもの もあるので、参考までにしてください また、使い込んでなくてニワカなものもあります 28
29. 2つのE2E自動テストツール • コード型 ◦ GUIはなく、コーディングによってテストケースを作成する。OSS であり、無償で使えるものがほとんど。 • ノーコード型 ◦ GUIがあり、コーディング不要でテストケースが作成できるも の。主にSaaSとして提供されていて、有償のものしかない(は ず)。 ◦ 古くからのリプレイキャプチャ形式や、Seleniumのラッパー的 なものなど多岐に渡る。 29 ※オレオレ定義です。
30. コード型 • Selenium webDriver • Cypress • TestCafe • Playwright • CodeceptJS • QA Wolf • Puppetteer • sikuli • 他にもたくさん 30 検討したもの
31. コード型のメリット・デメリット • メリット ◦ 実行が早い(特にheadless) ◦ 拡張が自由でI/O処理やDBアクセスなどもケース手順に含め られる ◦ gitで管理できる ◦ 無償である • デメリット ◦ 環境構築が大抵の場合面倒 ◦ ライブラリアップデートが必要 ◦ 並列処理するためにはCI/CD含めた設定が必要 ◦ フロントエンドの実装によってはテストケース作成難易度、およ びメンテナンスコストが非常に高い ◦ コーディング未経験のQAエンジニアやビジネスサイドから敬遠 されがち 31
32. コード型が『スタディサプリ』チームの検討から外れた理由 • メンテナンスコストが高くつきそうだった ◦ テストが安定しそうなロケーターの設定が、フロントエンドの実装上難しそうだと判断 (CSSクラス名をランダム生成していて、idやカスタムデータ属性が当時付与されてな かった) ◦ 環境構築面でもメンテの不安があった • IE対応しているツールが少なかった ◦ 当時だとSeleniumのみだった気がする • “いい感じ”に気を利かせてくれない ◦ Seleniumを例にすると、1画面内でリストエリアがあるとスイッチ処理が必要。待機も 明示的にしないといけない。(工夫の仕方はあるし、Playwrightだとデフォで待機し てくれたりはする) 32 ⇒Selenium、Cypressに限らずコード型の自動テストツールの 場合は、ロケーターの部分がどうしてもメンテコストが高くなると 考えて、検討から落とした
33. ノーコード型 • Autify • MagicPod • Mabl • Synthetic Monitoring • Ranorex • UiPath Test Suite • 他にもたくさん 33 検討したもの
34. ノーコード型のメリット・デメリット • メリット ◦ 学習コストが比較的低い ◦ 機械学習を用いたテストケースの自動修復機能が最近は大体 ある ◦ 実行時に”いい感じ”に気を利かせてくれることがある ◦ 実行時の画面をキャプチャしてwebサイトで一覧できる ◦ 【うちの評価外】画面差分によるVRT(ヴィジュアルリグレッション テスト)機能もあったりする • デメリット ◦ 有償である ◦ SaaSなので、提供している機能に限界がある ◦ 失敗時の原因がログから辿りにくい ◦ git管理できず、コード資産が残らない 34
35. Mablの特徴 • メリット ◦ Postmanと連携して、APIテストも合わせて簡単にできる ◦ Auto-healing機能により要素の自動修復がされ、メンテナンスが容易 • デメリット ◦ モバイルアプリの対応なし ▪ ※『スタディサプリ』はモバイルアプリもあるので、SaaSを使うなら対応している ものを探していた 35 モバイルアプリの対応がないという1点のみで、検討から外したが、 webのみで考えれば機能性は十分。むしろ、APIテストも含めたいな らば、最有力候補になると思われる
36. MagicPodの特徴 • メリット ◦ AIによる自動修復機能があり、メンテナンスが容易 ◦ assertが豊富 ◦ 手順の共有化ができ、どこでも呼び出せて、変数も渡すことができる ◦ ロケータを自分で調べる必要がなく、作成がSeleniumに比べてかなり楽 ◦ 実行回数による課金なし(並列度のみ) ◦ 実行速度はノーコード型の中ではかなり速い • デメリット ◦ 要素特定に一定レベルのHTML知識が必要になり、学習コストがある ◦ MagicPod自体のバグがたまにある ◦ 共有UIのメンテナンスなど、有識者の管理やサポートが必要 ◦ 同時並列実行数は10並列まで 36 提供している機能が豊富であり、QAエンジニアがツール利用をサ ポートできる環境なら適している。また、テスト実行回数がかなり多い 環境でも費用を気にしなくてよい。 『スタディサプリ』の中学講座チームで活用している。
37. Autifyの特徴 • メリット ◦ self-healingという自動修復機能によってメンテが容易 ◦ 画面操作のみでテストが作成でき、学習コストが圧倒的にかからない ◦ メールテストが簡単にできるようになっている ◦ 実行を並列実行か直列実行かを簡単に設定できる ◦ 企業ごとの固定IPが振られるので、セキュリティを満たしながら開発環境へアクセス できる ◦ 機能アップデートが早い ◦ どうしても困ったらJavaScript(JSステップ)で大体なんとかなる • デメリット ◦ 月の上限実行回数を超えると追加費用がかかる ◦ 同じ手順を別のテストケースから呼ぶことはできるが、制約がある ◦ テストケースの修正・編集時に再度レコーディング必要なのが面倒 37 非エンジニアでも簡単に活用ができ、導入から最初の立ち上がりが圧倒的に 優れている。E2E自動テストの有識者がいない組織に適している。 『スタディサプリ』のコーチングチームで活用している。
38. 各ツールの説明を踏まえて一言 ツールはたくさんあります。 “最強のE2E自動テストツール”というのは存在しません。 ノーコード型でもほとんどE2Eテストは実現できると思います。 色々試して、どれが自分の組織状況に合いそうかを考えてください。 その際にはE2Eテスト自動化の目的を忘れずに！ ツールはツールであり、E2Eテスト自動化は問題解決の手段の1つに過ぎな いので！ 38
39. FIN 39