持続可能なE2E自動テストを目指して / Towards sustainable E2E automated testing

2024/11/22
TECH Street主催の「テスト自動化エンジニア勉強会」にて登壇した際のスライドです。
https://techplay.jp/event/961465
「持続可能なE2E自動テストを目指して」
小島 大周 (@Dasihu) / 株式会社メドレー / QAエンジニア
---
巨大化しがちなE2Eテストに対して、QAエンジニア目線で最適化のために行ったアプローチについて実務ベースで紹介します。
弊社はMagicPodを利用しておりますが、他ツールでも適応できる内容なので、自動テストに携わる方々の参考になると嬉しいです。

Transcript

1. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 1 持続可能なE2E⾃動テストを⽬指して @Daishu 2024/11/22 テスト⾃動化エンジニア勉強会 〜各社の取り組みや課題から学ぶ会〜 向け
2. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 2 2022年⼊社  ‧医療 SaaS である        のプロダクト開発の⼀員  ‧プロジェクトのがっつりQA、E2Eテストの実装など 前職はSHIFT  ‧toC向けのWebアプリ企業にて、QAを3年間やっておりました 趣味 ⼩島 ⼤周 (Kojima Daishu) はじめに @Daishu プロダクト開発が好きです！ 👦⼦供と遊ぶ  🐩愛⽝のお世話  🐠アクアリウム         | QA Engineer
3. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 3 私が携わるプロダクトについて はじめに Web予約、問診、オンライン診療、電⼦カルテ、 レセコン、経営分析といった独⽴したシステムをすべて内包 クラウド診療⽀援システム 病院‧診療所
4. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 4 本発表の E2E テストはWebアプリが対象です はじめに 患者 クラウド診療⽀援システム iOS Android Web SaaS 予約‧問診‧オンライン診療‧決済.. 病院‧診療所 CLINICS(クリニクス) オンライン診療‧服薬指導アプリ E2Eテスト E2EテストはMagicPodというノーコードテストツールを利⽤しています QA/⾃動テストの担当領域
5. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 5 MagicPodとは 利⽤ツール ⽇本発のノーコード E2E テスト⾃動化サービス • 直感的に操作できるUI ◦ テストコードが書けなくても実装できる • 環境構築不要 ◦ Slack通知や定期実⾏の仕組みがあり、0 > 1フェーズもQAエンジニアで完結できる • コードライク ◦ 関数、変数、条件分岐に相当するコマンドがあり、コードっぽく表現できる • WEB‧モバイル対応 ◦ クラウドなのでテストインフラの対応 (SDKアップデート) 等を全てお任せできる ⾃動テストの環境構築‧実装‧保守のハードルをMagicPodがすべて吸収してくる
6. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 6 MagicPod 新機能の開発とコミュニティが活発 https://portal.magicpod.com/ 要望⼀覧がリストで公開されており、ユーザーも追加可能！開発状況も閲覧できる 専⽤Slackチャンネルでユーザー同⼠の情報交換‧相談もできる
7. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 7 MagicPodで作成できるE2Eテストの例 MagicPod 診察 処⽅箋送信 実ブラウザで動作するので、プロダクトを跨いだ⼀気通貫のE2Eテストもできる 予約 決済 「予約 〜 診察 〜 お薬受け取り」までのユーザーストーリー E2E 薬剤師 医師‧事務員 患者 ※薬局向けSaaS 患者Webアプリ
8. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 8 MagicPodを使ったE2Eテストの歩み
9. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 9 E2Eテストと向きあった1年間のおさらい これまで 項⽬ 1年前 実⾏頻度 週1 テストシナリオ数 3 総Step数 300 ヘルススコア 30点 ⾃動テストの健全性を⽰すヘルススコアというMagicPodの機能 改善前 • 不安定でほとんど不具合を拾えない • ⾃動化の恩恵を全く得られていない状況
10. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 10 E2Eテストと向きあった1年間のおさらい これまで 項⽬ 現在 実⾏頻度 毎⽇ テストシナリオ数 23 総Step数 3000以上 ヘルススコア 100点 改善後 • ⽇々のデイリー実⾏で、統合ブランチがstableであることを保証 • 前⽇にマージされたPRに含まれた不具合の検知 〜 翌朝のフィードバック 満点になるとMagicPod に褒められる演出があります🎉
11. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 11 詳細は下記スライド‧ブログをご覧ください これまで E2Eテストの信頼性と向き合ってMagicPodのヘルススコアが100に達した話 ヘルススコア100に到達した理由
12. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 12 「E2Eテストの実⾏時間、⻑すぎ！」問題に直⾯
13. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 13 テストケースが増えて実⾏時間も増加 E2Eテスト拡充後 2時間31分 テストケース数の増加で実⾏時間が伸びるのは当然だが、⻑すぎないか？
14. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 14 原因について考える
15. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 15 E2Eテストの実⾏時間が⻑くなった (巨⼤化) した主な原因 原因について考える ① ⼿動テストの⼯数削減を最優先にしてしまった • ⾃動テスト⽤に最適化されていないので、そのまま実装するとシナリオが⻑くなる • この細かな確認項⽬はE2Eテストとして必要か？の精査も省略していた ② 細かい仕様も「ついでに⾒ておくか」という気持ちで実装してしまった • MagicPodの実装容易さ • 開発側の⾃動テストの存在も認識していたが、⼿元で管理したい気持ちもあった.. ◦ そもそも、然るべきタイミングで実⾏されているか..?不明だった 結果：Unitテスト相当の確認項⽬がE2Eテストに実装される => E2Eテストの巨⼤化に繋がった
16. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 16 E2Eテスト実装時の当時の考え⽅ 原因について考える バリデーションの検証 MagicPod 実装画⾯ ワカリマシタ (いや、MagicPodなら検証できるけど、E2Eテストに含めてええんか..?) E2Eテストの中に、ついでにバリデーションの検証もいれておくか (さくっと)
17. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 17 E2Eテスト実装時の当時の考え⽅ 原因について考える メンテナンスは何とかできていたが、この状況に近づいていた 伊藤 望 “LeanとDevOpsのためにE2Eテストができること”
18. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 18 本⽇のメインテーマ 持続可能なE2Eテストを⽬指した最適化の取り組み
19. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 19 課題：Unitテスト相当の確認項⽬をE2Eテストに実装してしまった  ① 開発チームが利⽤する⾃動テストを理解した
20. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 20 先ほどの事例の続き‧‧ 開発側の⾃動テスト理解 開発者のテストコードを調べてみると、E2Eテストに実装した内容と重複！ 開発者作成のUnitテスト QAのE2Eテスト (MagicPod)
21. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 21 まさしくこの状況 開発側の⾃動テスト理解 伊藤 望 “LeanとDevOpsのためにE2Eテストができること”
22. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 22 開発チームの⾃動テストを確認しよう！
23. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 23 各テストフレームワークのテストレベルを整理 開発側の⾃動テスト理解 開発チームとSyncして、CLINICSで利⽤する⾃動テストを整理した Unit Integration E2E ⾼コスト 低コスト ← テストケースの数 → レベル CLINICSで動くテストフレームワーク  E2E テスト ：MagicPod  VRT ：regsuit + storycap, MagicPod  UI テスト ：Storybook + Vitest + React Testing Library  API テスト ：RSpec + Open API Schema + Committee, RSpec + VCR  Unit テスト ：Vitest (Front) , RSpec (Backend)
24. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 24 CLINICSが保有するテストフレームワーク 開発側の⾃動テスト理解  いつの間にか、CLINICSはテスタビリティの⾼いプロダクトになっていた..! クラウド診療⽀援システム ‼ 開発チームの⾃動テストについて、いざ蓋を開けてみると‧‧
25. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 25 アプリケーションの成熟に伴うテスタビリティの向上 開発側の⾃動テスト理解 中期的には、E2Eテストがカバーするシナリオは少なくなることが多いでしょう。 アプリケーションのテスタビリティが成熟するにつれ、技術的な制約からE2Eテストせ ざるを得なかったシナリオは、他のテストレベルでカバーされるようになるためです。 　” 末村 拓也「テスト自動化実践ガイド」 ” 現在のプロダクトの⾃動テストのテスタビリティを正しく把握することが重要だった
26. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 26 それぞれのテストの責務はなにか？ 開発側の⾃動テスト理解 レベル CLINICSにおける役割  E2E Test ：主要機能の疎通検証、ドメインロジック‧バリデーションの検証
27. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 27 それぞれのテストの責務はなにか？ 開発側の⾃動テスト理解 レベル CLINICSにおける役割  E2E Test ：主要機能の疎通検証、ドメインロジック‧バリデーションの検証  VRT ：画⾯レイアウトのリグレッション検知  UI Test ：コンポーネントの⾒た⽬を含めたロジック検証、ステータス毎のUIパターン網羅  API Test ：ドメインロジック‧バリデーションの網羅  Unit Test ：ドメインロジック‧バリデーションの網羅
28. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 28 それぞれのテストの責務はなにか？ 開発側の⾃動テスト理解 レベル CLINICSにおける役割  E2E Test ：主要機能の疎通検証、ドメインロジック‧バリデーションの検証  VRT ：画⾯レイアウトのリグレッション検知  UI Test ：コンポーネントの⾒た⽬を含めたロジック検証、ステータス毎のUIパターン網羅  API Test ：ドメインロジック‧バリデーションの網羅  Unit Test ：ドメインロジック‧バリデーションの網羅 E2Eテストの役割がUnitテストと⼀部重複‧‧
29. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 29 いつテストが動くのか？ 開発側の⾃動テスト理解 統合branch PR local push Merge つまり、E2Eテストに同じテストがあると単なるWチェックでしかない‧‧ 統合ブランチにマージされるまでに各テストが動いており、すべて通過してE2Eテストに回ってくる 統合ブランチでデイリー実⾏ Release ⾃動テスト実⾏タイミング
30. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 30 開発者にE2Eテストに対する期待値をヒアリング 開発側の⾃動テスト理解 主要な業務シナリオの担保 • UIの細かい挙動、ステータス‧ロジックの網羅は開発側の⾃動テストで担保できる • E2Eテストはクリティカルなシナリオのハッピーパスに絞って欲しい Backendを介したFrontの担保 • 開発チームのUIテストはネットワークを介していない • Backendを介してシステム間の疎通が取れるか⾒て欲しい 実ブラウザでしか検証が難しいもの • ブラウザバック、リロード、クロスブラウザなど CLINICSと密結合な外部サービスとの連携 • テストコードではサービスを跨いだテストが難しい ◦ 例：冒頭紹介した患者・薬局などの別サービスを跨いだ検証
31. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 31 改めてE2Eテストの役割について理解する 開発側の⾃動テスト理解 • E2Eテストのテストベースは、ユーザーストーリー • テスト対象は、完全に統合されたシステム全体 • 想定されるバグは、ユーザーストーリーそのものの失敗 • E2EテストはUnitテストで補完しあうことで、効率とカバレッジを最⼤化できる • ロジックの網羅はUnitテストに任せ、E2Eテストはシナリオベースに特化する 末村拓也 “テスト⾃動化実践ガイド” “Webフロントエンド E2E テスト” https://amzn.asia/d/3jPEGlb
32. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 32 CLINICSにおけるE2Eテストの役割を再認識 開発側の⾃動テスト理解 レベル CLINICSにおける役割  E2E Test ：主要機能のハッピーパスの疎通検証 ：E2Eでしか検証できないもの (ブラウザ機能‧サービス跨ぎ)  VRT ：画⾯レイアウトのリグレッション検知  UI Test ：コンポーネントの⾒た⽬を含めたロジック検証、ステータス毎のUIパターン網羅  API Test ：ドメインロジック、バリデーションの網羅  Unit Test ：ドメインロジック、バリデーションの網羅 CLINICSにおけるE2Eテストのあるべき姿が整理された
33. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 33 実際のストーリーで⾃動テストの棲み分けを考える 開発側の⾃動テスト理解 患者 来院 患者情報⼊⼒ 名寄せ 患者登録 新規患者 既存患者 事務員 通信 通信 受付 例：CLINICSにおける診察受付までのストーリー
34. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 34 実際のストーリーで⾃動テストの棲み分けを考える 開発側の⾃動テスト理解 患者情報⼊⼒ 名寄せ 患者登録 フォームのバリデーション ‧利⽤できない⽂字 ‧空欄 ‧不正な⽣年⽉⽇ UIバリエーション ‧患者属性ごとの表⽰ ‧ステータス表⽰ ‧ステータス毎のメニュー内容 エラーパターン ‧既に患者登録済み ‧同⼀時間に予約あり ‧例外エラー 新規患者 既存患者 事務員 通信 通信 受付 患者 来院 例：CLINICSにおける診察受付までのストーリー
35. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 35 実際のストーリーで⾃動テストの棲み分けを考える 開発側の⾃動テスト理解 患者情報⼊⼒ 名寄せ 患者登録 フォームのバリデーション ‧利⽤できない⽂字 ‧空欄 ‧不正な⽣年⽉⽇ UIバリエーション ‧患者属性ごとの表⽰ ‧ステータス表⽰ ‧ステータス毎のメニュー内容 エラーパターン ‧既に患者登録済み ‧同⼀時間に予約あり ‧例外エラー 新規患者 既存患者 事務員 通信 通信 受付 E2Eテスト担保？ E2Eテスト担保？ E2Eテスト担保？ 患者 来院 例：CLINICSにおける診察受付までのストーリー
36. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 36 実際のストーリーで⾃動テストの棲み分けを考える 開発側の⾃動テスト理解 患者情報⼊⼒ 名寄せ 患者登録 フォームのバリデーション ‧利⽤できない⽂字 ‧空欄 ‧不正な⽣年⽉⽇ 受付 UIバリエーション ‧患者属性ごとの表⽰ ‧ステータス表⽰ ‧ステータス毎のメニュー内容 エラーパターン ‧既に患者登録済み ‧同⼀時間に予約あり ‧例外エラー 新規患者 既存患者 事務員 Unitテスト担保 APIテスト担保 UIテスト担保 通信 通信 患者 来院 例：CLINICSにおける診察受付までのストーリー
37. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 37 実際のストーリーで⾃動テストの棲み分けを考える 開発側の⾃動テスト理解 患者情報⼊⼒ 名寄せ 患者登録 フォームのバリデーション ‧利⽤できない⽂字 ‧空欄 ‧不正な⽣年⽉⽇ 受付 UIバリエーション ‧患者属性ごとの表⽰ ‧ステータス表⽰ ‧ステータス毎のメニュー内容 エラーパターン ‧既に患者登録済み ‧同⼀時間に予約あり ‧例外エラー 新規患者 既存患者 事務員 E2Eで⾒るべき観点 ‧新規患者で受付まで⾏えること ‧既存患者を名寄せして受付できること 通信 通信 E2Eテスト担保 患者 来院 UIテスト担保 例：CLINICSにおける診察受付までのストーリー Unitテスト担保 APIテスト担保
38. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 38 開発者のテストをブラックボックスにしない 開発側の⾃動テスト理解 テストコードを⾒ないでE2Eテストを実装すると「あれもこれも」となり、棲み分けが崩れやすい
39. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 39 開発側の⾃動テスト理解 ✅ 開発者のテストを確認した上で、E2Eテストを実装していく ✅ Unitレベルで⼊れたい観点は、開発者のテストに追加依頼していきたい Unitテストに観点追加お願いします！ 事前に読んで‧‧ E2Eテスト実装！ テスト観点追加！ E2Eテスト最適化のサイクル E2Eテストの最適化の考え⽅
40. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 40 E2Eテスト側も開発者に対してブラックボックスにしない 開発側の⾃動テスト理解 例：機能⼀覧とE2Eテストをマッピングしたシート どんなE2Eテストがあるのか？外から⾒えるように⼯夫をしています E2Eテストのカバレッジも計算できるのでオススメです！
41. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 41 課題：Unitテスト相当の確認項⽬をE2Eテストに実装してしまった  ② ⾃動テストによる障害の再発防⽌の考えを改めた
42. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 42 ある⽇のできごと 障害の再発防⽌ それならMagicPodを使って再発防⽌のE2Eテストの実装終わってます！ 先⽇に起きた障害を振り返って、再発防⽌検討しようか お、おう (E2Eテストでいいんだっけ..?)
43. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 43 障害の再発防⽌にE2Eを利⽤するのは最終⼿段 障害の再発防⽌ ❌障害の再発防⽌は⼀度⼊れると削除しづらくE2Eテストの運⽤コストが増⼤していく • 検討なしで初⼿「E2Eテスト担保」は避けたい • 削除しづらいだけでなく「何のためのテストだっけ？」となりやすい • 最もコストが安いところで対応できないか？を検討したい Unit Integration E2E Unitテスト > ITテスト > E2Eテストとボトムアップで検討 コスト⼤ コスト⼩ テストピラミッド
44. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 44 まとめていきます
45. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 45 冒頭のエピソードの振り返り まとめ ⼿動テストの⾃動化‧E2EテストのUnitテスト相当の項⽬が増えていくと‧‧ テスト巨⼤化 > メンテコスト増 > 容易に流せない > E2Eテストの価値貢献の低下
46. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 46 E2Eテストの巨⼤化を防ぐために まとめ ⼿動テストの⾃動化 • ⼿動のリグレッションテストケースを⼿始めに⾃動化するのは良いが、無邪気に⾃動化 するとE2Eテストの巨⼤化に繋がる懸念あり • ⾃動テスト向けに最適化して実装したい E2Eテストで⾒るべきもの • E2Eテストはプロダクトの数ある⾃動テストの内の1つであり、トータルで品質保証して いく考えで拡充していく • ロジックやパターンの網羅は、Unitテストレベルに寄せる • 開発者とQA相互で「⼀緒に⾃動テストを拡充しよう」というスタンスを持つ ⾃動テスト全体の最適化して、⾼品質な価値提供のスピードアップに繋げていく
47. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 47 持続可能なE2Eテスト まとめ プロダクトのテスタビリティを理解して、開発者とE2Eテストの役割の認識を揃えることで、 メンテ不能に陥らず、持続的に価値貢献できるE2Eテストを⽬指せる！
48. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 48 (再掲) CLINICSにおけるE2Eテストの役割 まとめ レベル CLINICSにおける役割  E2E Test ：主要機能のハッピーパスの疎通検証 ：E2Eでしか検証できないもの (ブラウザ機能‧サービス跨ぎ)  VRT ：画⾯レイアウトのリグレッション検知  UI Test ：コンポーネントの⾒た⽬を含めたロジック検証、ステータス毎のUIパターン網羅  API Test ：ドメインロジック、バリデーションの網羅  Unit Test ：ドメインロジック、バリデーションの網羅 ※ プロダクトのテスタビリティに応じてE2Eの役割は変わるので、開発者と要調整
49. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 49 その後どうなったか
50. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 50 E2Eテストの棲み分けはどうなったか？ その後 ✅MagicPodでしか担保できないケースのテスト観点の追加依頼をいただく
51. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 51 再発防⽌策はどうなったか？ その後 ✅⾃動テスト全体を⾒据えてQAと開発者で再発防⽌策を検討できている
52. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 52 実⾏時間はどうなったか？ その後 改善後 改善前 2時間31分 2時間42分 ✅E2Eテストでカバーするストーリーの数は増えたが、実⾏時間は抑えられている
53. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 53 E2Eテストの⾏く末
54. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 54 E2Eテストは増やしちゃいけないのか？ E2Eテストの⾏く末 • 必要なら増やして良い ◦ E2Eテストを増やしたい = 担保すべきユーザーストーリーが増えたということ ◦ つまり、プロダクトが成⻑している証 • E2Eテストが増えることが悪ではない ◦ 他の⾃動テストとのバランスが崩れないことが⼤事 ◦ バランスを保って増やしていく • ⻑期的にはユースケースの増⼤とともにE2Eテストの数はさらに増える • ユースケースが増えるということは、それだけビジネスが成熟しているともいえる • ビジネスの成⻑とともにE2Eテストが順次増えていく形が理想的 　” 末村 拓也「テスト自動化実践ガイド」”
55. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 55 E2Eテストは増やしちゃいけないのか？ E2Eテストの⾏く末 Unit E2E Integration Unit E2E Integration Unit E2E Integration プロダクトのグロースと共にテストピラミッドを⼤きくする！ • 必要なら増やして良い ◦ E2Eテストを増やしたい = 担保すべきユーザーストーリーが増えたということ ◦ つまり、プロダクトが成⻑している証 • E2Eテストが増えることが悪ではない ◦ 他の⾃動テストとのバランスが崩れないことが⼤事 ◦ バランスを保って増やしていく
56. Copyright© Medley, Inc. ALL RIGHTS RESERVED. 56 ご清聴ありがとうございました！