『スタディサプリ 中学講座』における E2E Test の運用と計測による改善

2023/07/14 MagicPodユーザーLT会での発表資料
https://trident-qa.connpass.com/event/283709/

後編はchaspy
https://speakerdeck.com/chaspy/improved-e2e-testing-through-measurement

Transcript

1. 『スタディサプリ 中学講座』における E2E Test の運用と計測による改善 株式会社リクルート 2023/07/14 MagicPodユーザーLT会

2. 前編　E2E Testの運用 2
3. 3 自己紹介 本名: 井上 達斗(いのうえ たつと) Twitter/Slack名: testtatto 経歴: • 派遣でテスト実施の仕事をし始めたのがテストエンジニアの始まり • ベリサーブでプロジェクト型の案件に従事 • リクルート(元Quipper)では1人目のQAエンジニアとして、チームの 立ち上げやE2E自動テストの導入、文化作りを行っている
4. 前置き • 話すこと ◦ 前編では、後編の計測の話の前提を共有するのがメイン ▪ デプロイフロー ▪ MagicPodの実行タイミング ▪ テストケース作成ルール ▪ メンテナンス ◦ MagicPodの運用での工夫も少し紹介 4
5. 5 Outline 1. 自己紹介 2. 『スタディサプリ 中学講座』におけるデプロイフロー 3. MagicPodの運用での工夫 4. 前編のまとめ
6. 2. 『スタディサプリ 中学講座』におけるデプロイフロー 6
7. スタディサプリについて 7 ※サービスとしてはモバイルアプリ (iOS/Android)もありますが、今日話す 対象はPCブラウザのみのスコープです
8. 『スタディサプリ 中学講座』チームのリリース 開発者が任意のタイミングで、かつ、 マイクロサービス単位でリリースしている！ その際に手動のリグレッションテストはなく、 MagicPodによるリグレッションテストをフローに組み込んでいる 8
9. なぜリリースをこのようにしているのか？ 価値あるものを早く届けるため 9 計画 開発 価値の 提供 仮説・検証
10. デプロイフロー 10
11. デプロイフロー上の品質担保 11 赤枠部分が品質担保のための活動
12. デプロイフロー上の品質担保 12 新規実装箇所の機能性担保目的 新規実装によるデグレ検知目的
13. MagicPodの利用によるメリット • このデプロイフローによるMagicPodの価値 ◦ ちょっとした不具合修正などを即座にリリースできる ◦ 開発⇒QAとエンジニアの境界になる部分をシームレスに実行 することができる ◦ 開発者が安心感を持ってリリースできる(生の声) 13 ⇒MagicPodが、Agile Testingの 実現に一役買っている
14. 3. MagicPodの運用での工夫 14
15. テストケースの作成ルール テストケースは開発者全員が作成する！ ◦ QAはあくまでフォロー。アサインは基本的には機能開発に関 係した開発者。 15
16. テストケース作成の流れ 16
17. 定例で話していること(ざっくりイメージ) 17 この機能のユーザーにとってのコアの部分ってここですよね？ ここが守られてれば良さそうですね。 データパターン考えますか。 QA 開発者 そろそろxx機能がリリースしますが、 E2E自動テストケースどうしましょ？ 開発者 実装ロジックは～になっていて、テストコードでパターン網羅はされてますね じゃあE2Eレベルでは一連のフローが担保できてれば良さそうですね 確認としてはここにAssertが入る感じかな～？ QA 開発者 フロントエンド側はバックエンドから渡されたものをそのまま表示してるだけで、バックエンド 側にはこういうテストがあるから、それで良さそうですね 以下、アサイン決めだったり、共有ステップ作るかとか、データはこれを使おう とか、に続く
18. 工夫ポイント • 作成するケースについては週次の定例で精査する ◦ そもそも、E2E自動テストを太らせたくないので、テストレベルに 合ったケースのみを作成するようにしている ◦ ケース内の確認項目についてもテストレベルを意識する 18 開発者とQAが話し合うことで、「E2E自動テストで守りたい部分」を 明確にし、テストピラミッドを崩さない！
19. テストケースのメンテナンス • テストがこけた場合には失敗したテストケースごとのオーナーの チーム(機能単位)が担当する ◦ QAはそのフォロー • リリース速度を優先するため、テストケース修正はリリース後で対応 でよいことにしている ◦ こけたテストケースと同じ確認を手動テストで確認できればリ リースする ◦ 割れ窓にならないようになるべく当日中の修正を行う ◦ 事前に落ちることがわかっている場合は、ラベルによって一時 的に実行対象から外す 19
20. このやり方によるメリット・デメリット • メリット ◦ 開発者がE2Eテストに関わるので、単体テストや結合テストとの 境界漏れが少なくなる ◦ E2E自動テストでflakyになりやすいフロントエンドの実装が肌 で感じられる。テスト容易性を意識した実装をしてくれる • デメリット ◦ 開発者の学習コスト 20 ⇒チーム全体の品質文化の醸成 ⇒適切な共有UIルール、共有ステップ の用意で軽減している
21. 3. 前編のまとめ 21
22. 3行まとめ • 価値を早く届けるためにリリースは開発社の任意のタイミングで行 われている • MagicPodのE2E自動テストをリグレッションテスト目的でデプロイフ ローに組み込んでいる • ケース作成やメンテナンスを開発者がやることで、チーム全体の 品質文化が醸成される 22