0->1 フェーズで E2E 自動テストを導入した私たちの、これまでとこれから

https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16447/01-e2e

Transcript

1. スライドトップと
 してご利用ください
 マネーフォワード事業本部 
 山田 太郎
 © Money Forward, Inc. 0 → 1 フェーズで E2E 自動テストを導入した 私たちの これまでとこれから 株式会社マネーフォワード Hiroaki Nishijo / Yoya Kobayashi © Money Forward, Inc. 2022.05.21 Scrum Fest Niigata 2022
2. 西條 広晃 (Nishijo Hiroaki) @jojojo_no_jo https://note.com/nishijo_hiroaki/ © Money Forward, Inc. マネーフォワード 　クラウド会計: QAマネージャー 　クラウド確定申告: 初代担当 経歴 • 2009〜2014　SESで開発&テスト • 2014〜2018　ネット証券会社でテスト • 2018〜　マネーフォワード JOIN
3. 小林 羊哉 (Kobayashi Maya / yoya) @yoya_k 　 https://note.com/yoya_k マネーフォワード クラウド確定申告 2代目QAリーダー Markin’ Quality レギュラーメンバー (1日目の懇親会ジャックしたチームです！) 経歴 • 2009〜2016　小売業向けシステム開発 • 2016〜2019　ブラウザゲーム開発 • 2019〜　マネーフォワード JOIN 　　　　　＆ QAエンジニアに転身 © Money Forward, Inc.
4. © Money Forward, Inc. 本セッションでお話しするE2Eテストは UIテストのことを指しています はじめに おことわり Unit Tests Integration Tests UI Tests
5. © Money Forward, Inc. みなさん E2Eテストの自動化やってますか？ いつから 自動化をはじめましたか？ ノーコード？ ローコード？ 順調？ 難航中？ ローンチ前？ 運用に 入ってから？
6. © Money Forward, Inc. リリースするまではUIの変更も多いだろうし、 やっぱり運用フェーズに入ってから よく実行するテストケースを自動化するのが 定石じゃないですか？ そんなことないよ！！ ええっ！？ というのが今回のお話。
7. © Money Forward, Inc. 本題に入る前に…　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ◀ 2020年フルリニューアル！ 　個人事業主のための確定申告作業をラクにする 　クラウド型確定申告ソフト • 青色申告や白色申告に対応 • 確定申告書Bや青色申告決算書など 申告に必要な書類の自動作成が可能 • 2021年から分離課税・損失申告も可能に！ アプリで確定申告をより簡単に！ ▶ iOS、Androidそれぞれ提供 日々の仕訳業務から マイナンバーカードを利用した 確定申告書提出まで1つのアプリで完結できる とは
8. © Money Forward, Inc. 2013 2020 2021.06 リリース フルリニューアルプロジェクト 2月 キックオフ 11月 リリース！ ・・・・・・ 本日の話の流れ 導入篇 運用篇
9. 導入篇
10. © Money Forward, Inc. プロジェクトが動き出した時の様子は？ Sprint 0 期間：約2ヶ月 やったこと PdM： • ユーザーニーズの把握や要件まとめ（ペルソナ作成など） チーム： • インセプションデッキの作成 • ペルソナを元にしたワークショップに参加 • ユーザーストーリーマッピングをプロジェクト関係者全員で作成 QAE： • どのように品質保証を進めるかを考える
11. • PJ開始当初から以下の条件のもとで進める必要があった ◦ スコープが広い ◦ ほぼ確定した納期がある ◦ スクラムを組んでイテレーティブな開発を行う ◦ 他PJとの兼ね合いで潤沢なQAリソースは見込めない © Money Forward, Inc. どのように品質保証を進めるか？ 〜前提〜
12. • できるだけ前工程でバグを潰す ◦ 要件やデザインのレビューを行い、他機能との関連性やデザインの 統一性などを確認 • 不具合の資産化 ◦ 不具合情報を資産として残せるよう、不具合管理を継続して行う © Money Forward, Inc. どのように品質保証を進めるか？ 〜作戦1〜
13. • QAチェックを効率よく効果的に行う工夫 ◦ スコープ、デリバリー、QAEリソースを加味して、実装が完了した機能に対して 受入基準ベースの探索的テストを実行する ◦ 探索的テストの内容を自動化し、後続のSprintでリグレッションテストとして 実行できるようにするのがQCDのバランス的に最善だと考えた ◦ QAEリソースに余裕ができた場合は積極的にリソースを投入し、いろんな視点で のチェックを行う © Money Forward, Inc. どのように品質保証を進めるか？ 〜作戦2〜
14. • QAチェックを効率よく効果的に行う工夫 ◦ スコープ、デリバリー、QAEリソースを加味して、実装が完了した機能に対して 受入基準ベースの探索的テストを実行する ◦ 探索的テストの内容を自動化し、後続のSprintでリグレッションテストとして 実行できるようにするのがQCDのバランス的に最善だと考えた ◦ QAEリソースに余裕ができた場合は積極的にリソースを投入し、いろんな視点で のチェックを行う © Money Forward, Inc. どのように品質保証を進めるか？ 〜作戦2〜 🔦自動E2Eテストの導入検 討はここから始まりました。
15. • Must ◦ 使いやすいフレームワークであること ◦ 開発が継続して行われていること、ドキュメントが整っていること ◦ テスト結果をわかりやすく集計してくれること ◦ 各種CIツールで利用できること • Need ◦ テストケースが直感的に書けること ◦ 誰でも書けること • Want ◦ Spec/Stepの概念があると嬉しい、SpecがMarkdownなどで書けると嬉しい ◦ 日本語が使えると嬉しい © Money Forward, Inc. 自動E2Eテスト導入まで道のり 〜選定条件〜
16. 条件に合致した gauge+TAIKO を採用することに決定！ © Money Forward, Inc. 自動E2Eテスト導入まで道のり 〜採用〜 参照：gauge.org

17. © Money Forward, Inc. • https://gauge.org/ • SpecがMarkdown形式で書ける • 実装部分は複数言語サポート ◦ 確定申告ではjsを採用 • https://taiko.dev/ • Chromiumベースの自動テスト用API • Gaugeとセットで利用することが推奨 されている メリット • Markdown形式のためレビューしやすい • taiko APIを利用することで、エンジニア経験が浅いメンバーでも実装が可能 • GitHubでソース管理しているため、Sprintごとの差分やレビュー記録が参照しやすい gaugeとTAIKOについてちょっと紹介
18. © Money Forward, Inc. 2020.5.7 初めて画面のテストをpushするまで 2020.3.5 PJ本格始動！ Specのない 初期構成をpush 2020.5.20 初めて画面の テストをpush ・・・・・・ Sprint 0 の中盤 〜 Sprint 2 Sprint 3 Sprint 4
19. • gauge+TAIKO+Headless Chrome（以降同じ） • 自分の業務用Macbook Pro 1台 • ケースが少なかったので直列で実行していた • 実行時間は30分くらい © Money Forward, Inc. 実行環境 〜導入初期〜
20. © Money Forward, Inc. 実行環境 〜導入中期〜 • 導入中期 前半 ◦ 直列で1時間半位かかるようになってきた ▪ →並列化（8並列） ◦ まだ自分の業務用Macbook Pro 1台 • 導入中期 後半 ◦ さらにケースが増えて3時間位 ▪ →クラウドサーバに環境構築 ◦ と自分の業務用Macbook Pro 1台 ◦ 重要度の低いテストケースを実行対象外に ◦ 各8並列の計16並列で2時間くらい
21. • クラウドサーバのメモリを増強して、全て クラウドサーバ上で処理できるようにした • Jenkinsからキックできるようにした • 20並列で大体1時間15分位 • 30分位かかるSpecがある ◦ 並列数を増やしてみたりした ▪ これ以上並列化しても時間短縮 は見込めず © Money Forward, Inc. 実行環境 〜導入後期〜 jenkins.io

22. • 一人で対応していたので辛かった... ◦ 1Sprint 2week ▪ 1Sprintの前半に探索的テスト ▪ 1Sprintの後半に自動E2Eテストの実装 ◦ 加えて、グループリーダー業務＋プロジェクト掛け持ち • 時間に追われてドキュメントを残せていなかった... ◦ mayaさんごめんなさい © Money Forward, Inc. 困ったこと・課題 〜その1〜
23. • 取りきれない不具合はもちろん存在した... • ランダムフェイルが多い... • クロスブラウザの対応ができなかった...（Chromeのみ） © Money Forward, Inc. 困ったこと・課題 〜その2〜
24. • 0→1フェーズだからという理由で困ったことはない（と思う） ◦ 最初に目的や方針を明確にしていたのが良かったかも ▪ 作るケースの粒度があまりブレなかった ◦ Sprint 0でインセプションデッキやユーザーストーリーマッピングの構築に 参加できたのも良かったかも ▪ プロダクトが目指している姿の解像度が高かった ◦ テスト実装の前に要件やデザインのレビューができていたのも良かったかも ▪ テスト観点の整理が早い段階でできた © Money Forward, Inc. 良かったこと 〜その1〜
25. • やりきれたこと • gauge+TAIKOだからという理由で困ったことはない • SpecがMarkDownで残るのから超Good • 新機能実装時に既存機能の手動リグレッションテストの工数をだいぶ省ける • 自動テストの動作確認時にもう一回機能のチェックができる © Money Forward, Inc. 良かったこと 〜その2〜
26. • 個人的には0→1フェーズでE2Eテストの自動化に取り組むのも悪くないなと思った ◦ 正直めちゃめちゃうまく行ったとは思ってない ◦ 変更が頻繁に入るプロダクトやプロジェクトだともっとつらみが凄そう ◦ QAEのプロダクトやプロジェクトへの関わり方によっても変わってきそう © Money Forward, Inc. 導入篇まとめ プロダクトやプロジェクトの性質、払えるコスト、スケジュールなどから 適切に判断する必要がありそう
27. © Money Forward, Inc. 運用篇
28. © Money Forward, Inc. 怒涛の1stリリースを経て…… • いちプロジェクトだったチームは、個人事業主本部として独立へ ◦ モバイルアプリ版の開発チームも合流 • QA組織も併せて再構築することに ◦ 別プロジェクトに従事していた yoya に白羽の矢が立ったのだが…… noteリンクはこちら
29. © Money Forward, Inc. PO / PdM + Domain Expert + Designer + QA Feature Team B 個人事業主が 日常的に使えるアプリへ！ Feature Team A 確定申告の機能を 充実させよう！ PBI Item 1 Item 2 Item 3 Item 4 Item 5 ・ ・ ・ Product 背景：One Team Scrum から LeSS へ 1Sprintの期間も、この頃には2週間 → 1週間となっていた
30. © Money Forward, Inc. 背景：実は結構難しい、確定申告という仕組み 入出力のパターンがかなり多い • そもそも項目が多い ◦ 画面数も所得の種類などに合わせて 多くなっていた • 複数の閾値が絡み合う ◦ 年齢や所得額によって異なる計算式 ◦ 所得の種類も複数 • 法令の絶妙な言い回し ◦ 合計所得金額 ≠ 総所得金額等 ≠ 総所得金額 分離課税と損失申告 (2021年のマイルストーン) • 同じ名前の所得でもケースによって異なる課税形式 (ex. 上場株式等の配当等) • 所得金額の再計算が入るため、計算式も難易度UP (参考) 令和3年分所得税及び復興特別所得税の手引き(確定申告書B用)
31. © Money Forward, Inc. • 複数のフィーチャーチームに分かれたことで爆増したスクラムイベント ◦ QAがスクラムイベントの参加を減らすことによるリスクは これまでの経験で理解していた ◦ というわけで、全部参加 ▪ 更に当初、 リファインメントが PO<->開発 と PO<->デザイナーの2セットあった ▪ それぞれのスクラムイベントが長時間になりがち • これは半年後くらいに解消されるが、それはまた別のお話 早速キャパオーバー
32. © Money Forward, Inc. • 「QAさんのテストやレビューがOKにならないとDoneにならないんです」 ◦ (QAが当たり前に開発フローの中に入っているのはありがたい話だと思いつつ) ◦ そもそもこれまでの1年分の仕様やその背景を知らない状態からのスタート ▪ 前年のプロダクトバックログアイテム(PBI)と 国税庁のページを都度検索しながらのテスト ▪ Sprint前半はデザインレビュー、後半は仕様書レビューと探索的テスト • じっくり仕様を理解する時間が取りにくい ◦ 次Sprintに持ち越してしまうPBIが徐々に増えていった… 早速キャパオーバー
33. © Money Forward, Inc. そしてE2E自動テストはどうなったか • 慣れるまでは西條さんが実行とメンテを担当するということで合意していたが…… ◦ 結局余裕の無いまま、3ヶ月くらいお願いすることに • E2E自動テストの中でどんなシナリオが実行されて、 何が担保されているのかほとんどわからない、ブラックボックス状態が続いた ◦ すでにシナリオは400件近くある ◦ それぞれのシナリオの意図を読み解くのが難しい内容になっていた ▪ 「なんでこの入力でこの出力結果になるんだろう？」 「なんでこの表示をチェックしている(or していない)んだろう？」 → 根拠となる計算式やPBIを探し出すのに1〜2時間…
34. © Money Forward, Inc. • 新規画面のシナリオを作る余裕がない • シナリオ修正もひとりで抱え込むことに ◦ QAチームの他のメンバーは開発未経験 ▪ 教える余裕がない ▪ 何から教えればいいのか考える余裕もない • その結果 ◦ 深夜までシナリオ修正する日が度々発生していた ◦ 「E2E自動テストで何がテストされているのかわからない」 というチーム内での不満が溜まっていくのを感じる 実装・実行も引き継いだが…… JSの構文を見せても 伝わるかな… Gitは コマンド教えるだじゃ ダメだよね…
35. Gauge道場 開設します！！！ © Money Forward, Inc. そして2021年末、決意した
36. © Money Forward, Inc. 週に1回、60〜90分くらいのハンズオン 1. バージョン管理の基礎 2. GitHubの使い方 3. ローカルでGaugeを実行してみよう 4. モブプロで簡単なシナリオ実装 5. PRを出してみよう 6. ブランチの運用について Gauge道場とは
37. © Money Forward, Inc. その結果…… みんなにはきっと難しいと 勝手に決めつけて 壁を作っていたんだな… • 想定より1ヶ月前倒しでシナリオ実装が進んだ • シナリオの修正が必要な箇所を 自主的にタスク化するようになった • 手動テストの要否を既存のシナリオから 判断できるようになった ◦ ＝負担が大幅に減った！ • なにより メンバーの目が輝いてきた！！！
38. © Money Forward, Inc. • いつ、何のPBIによって発生したシナリオ修正なのか コミットログやPRに残る ◦ シナリオの意図が第3者からも掴みやすい • 複数人でコードを触ると何が起きるか、というのを身をもって体験できる ◦ なぜブランチを作成する必要があるのか ◦ なぜデグレやコンフリクトが発生するのか ◦ ここから開発者の気持ちを考えるきっかけになる GitHub を使うことによる副次的な効果
39. © Money Forward, Inc. • 「ノーコードの自動テストツールに乗り換えることも検討した方がいい」と 西條さんに言われたことがあったが、その選択は取らなかった • 実装経験を積む機会を回避させることが 最善だとは思えなかった ◦ E2Eテスト以外にも、ノーコードではないツールを 使ってみたい・作ってみたいというタイミングは必ずどこかで出てくる ◦ どこかで一歩目を踏み出さないと、可能性は広がらない • ここでやれなかったら、どこでやるの？ ◦ 一番挫折しがちな環境構築は済んでいて、運用もしている ◦ 少なくとも今1人、教えられる開発経験者がいる(＝私) Gaugeを使い続ける理由 (1)
40. © Money Forward, Inc. • テキストベースでシナリオを記述できる強み ◦ コメントを柔軟に残しやすい ▪ 最近は途中計算や背景となったPBIのリンクを手厚めに記載している ◦ QA以外のメンバーに共有しやすい ▪ シナリオの一部をSlackにコピー＆ペーストして挙動を相談することも ◦ 差分の比較もしやすい ▪ 毎年更新される様式と「5年前までさかのぼって申告できる」という要件 ▪ プロダクトコードもE2Eテストのシナリオも、 最大5つのバージョンを維持しなければならない Gaugeを使い続ける理由 (2)
41. © Money Forward, Inc. リニューアル版 クラウド確定申告のリリースから約2年 • これまでに作成されたPBI　2,000件以上 • 複雑さゆえに重厚化していく要件と仕様 ドキュメントを残すだけでは 「現在どのように動作しているのか」という疑問や不安を カバーし続けるには限界がある だからこそ 「具体的な入出力」を「ユーザーと同じふるまいで」 メンテナンスし続ける「生きた手順書」 が必要 動き続ける、生きた手順書
42. ご清聴ありがとうございました © Money Forward, Inc. QA Engineer 積極採用中です まずはカジュアルにお話しましょう！