Slide 1

Slide 1 text

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


Slide 2

Slide 2 text

前編 E2E Testの運用 2

Slide 3

Slide 3 text

3 自己紹介 本名: 井上 達斗(いのうえ たつと) Twitter/Slack名: testtatto 経歴: ● 派遣でテスト実施の仕事をし始めたのがテストエンジニアの始まり ● ベリサーブでプロジェクト型の案件に従事 ● リクルート(元Quipper)では1人目のQAエンジニアとして、チームの 立ち上げやE2E自動テストの導入、文化作りを行っている

Slide 4

Slide 4 text

前置き ● 話すこと ○ 前編では、後編の計測の話の前提を共有するのがメイン ■ デプロイフロー ■ MagicPodの実行タイミング ■ テストケース作成ルール ■ メンテナンス ○ MagicPodの運用での工夫も少し紹介 4

Slide 5

Slide 5 text

5 Outline 1. 自己紹介 2. 『スタディサプリ 中学講座』におけるデプロイフロー 3. MagicPodの運用での工夫 4. 前編のまとめ

Slide 6

Slide 6 text

2. 『スタディサプリ 中学講座』におけるデプロイフロー 6

Slide 7

Slide 7 text

スタディサプリについて 7 ※サービスとしてはモバイルアプリ (iOS/Android)もありますが、今日話す 対象はPCブラウザのみのスコープです

Slide 8

Slide 8 text

『スタディサプリ 中学講座』チームのリリース 開発者が任意のタイミングで、かつ、 マイクロサービス単位でリリースしている! その際に手動のリグレッションテストはなく、 MagicPodによるリグレッションテストをフローに組み込んでいる 8

Slide 9

Slide 9 text

なぜリリースをこのようにしているのか? 価値あるものを早く届けるため 9 計画 開発 価値の 提供 仮説・検証

Slide 10

Slide 10 text

デプロイフロー 10

Slide 11

Slide 11 text

デプロイフロー上の品質担保 11 赤枠部分が品質担保のための活動

Slide 12

Slide 12 text

デプロイフロー上の品質担保 12 新規実装箇所の機能性担保目的 新規実装によるデグレ検知目的

Slide 13

Slide 13 text

MagicPodの利用によるメリット ● このデプロイフローによるMagicPodの価値 ○ ちょっとした不具合修正などを即座にリリースできる ○ 開発⇒QAとエンジニアの境界になる部分をシームレスに実行 することができる ○ 開発者が安心感を持ってリリースできる(生の声) 13 ⇒MagicPodが、Agile Testingの 実現に一役買っている

Slide 14

Slide 14 text

3. MagicPodの運用での工夫 14

Slide 15

Slide 15 text

テストケースの作成ルール テストケースは開発者全員が作成する! ○ QAはあくまでフォロー。アサインは基本的には機能開発に関 係した開発者。 15

Slide 16

Slide 16 text

テストケース作成の流れ 16

Slide 17

Slide 17 text

定例で話していること(ざっくりイメージ) 17 この機能のユーザーにとってのコアの部分ってここですよね? ここが守られてれば良さそうですね。 データパターン考えますか。 QA 開発者 そろそろxx機能がリリースしますが、 E2E自動テストケースどうしましょ? 開発者 実装ロジックは~になっていて、テストコードでパターン網羅はされてますね じゃあE2Eレベルでは一連のフローが担保できてれば良さそうですね 確認としてはここにAssertが入る感じかな~? QA 開発者 フロントエンド側はバックエンドから渡されたものをそのまま表示してるだけで、バックエンド 側にはこういうテストがあるから、それで良さそうですね 以下、アサイン決めだったり、共有ステップ作るかとか、データはこれを使おう とか、に続く

Slide 18

Slide 18 text

工夫ポイント ● 作成するケースについては週次の定例で精査する ○ そもそも、E2E自動テストを太らせたくないので、テストレベルに 合ったケースのみを作成するようにしている ○ ケース内の確認項目についてもテストレベルを意識する 18 開発者とQAが話し合うことで、「E2E自動テストで守りたい部分」を 明確にし、テストピラミッドを崩さない!

Slide 19

Slide 19 text

テストケースのメンテナンス ● テストがこけた場合には失敗したテストケースごとのオーナーの チーム(機能単位)が担当する ○ QAはそのフォロー ● リリース速度を優先するため、テストケース修正はリリース後で対応 でよいことにしている ○ こけたテストケースと同じ確認を手動テストで確認できればリ リースする ○ 割れ窓にならないようになるべく当日中の修正を行う ○ 事前に落ちることがわかっている場合は、ラベルによって一時 的に実行対象から外す 19

Slide 20

Slide 20 text

このやり方によるメリット・デメリット ● メリット ○ 開発者がE2Eテストに関わるので、単体テストや結合テストとの 境界漏れが少なくなる ○ E2E自動テストでflakyになりやすいフロントエンドの実装が肌 で感じられる。テスト容易性を意識した実装をしてくれる ● デメリット ○ 開発者の学習コスト 20 ⇒チーム全体の品質文化の醸成 ⇒適切な共有UIルール、共有ステップ の用意で軽減している

Slide 21

Slide 21 text

3. 前編のまとめ 21

Slide 22

Slide 22 text

3行まとめ ● 価値を早く届けるためにリリースは開発社の任意のタイミングで行 われている ● MagicPodのE2E自動テストをリグレッションテスト目的でデプロイフ ローに組み込んでいる ● ケース作成やメンテナンスを開発者がやることで、チーム全体の 品質文化が醸成される 22