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

Slide 1

Slide 1 text

スライドトップと  してご利用ください  マネーフォワード事業本部   山田太郎  © Money Forward, Inc. 0 → 1 フェーズで E2E 自動テストを導入した私たちのこれまでとこれから株式会社マネーフォワード Hiroaki Nishijo / Yoya Kobayashi © Money Forward, Inc. 2022.05.21 Scrum Fest Niigata 2022

Slide 2

Slide 2 text

西條広晃 (Nishijo Hiroaki) @jojojo_no_jo https://note.com/nishijo_hiroaki/ © Money Forward, Inc. マネーフォワード　クラウド会計: QAマネージャー　クラウド確定申告: 初代担当経歴 ● 2009〜2014　SESで開発&テスト ● 2014〜2018　ネット証券会社でテスト ● 2018〜　マネーフォワード JOIN

Slide 3

Slide 3 text

小林羊哉 (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.

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© Money Forward, Inc. 本題に入る前に…　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ◀ 2020年フルリニューアル！　個人事業主のための確定申告作業をラクにする　クラウド型確定申告ソフト ● 青色申告や白色申告に対応 ● 確定申告書Bや青色申告決算書など申告に必要な書類の自動作成が可能 ● 2021年から分離課税・損失申告も可能に！アプリで確定申告をより簡単に！ ▶ iOS、Androidそれぞれ提供日々の仕訳業務からマイナンバーカードを利用した確定申告書提出まで1つのアプリで完結できるとは

Slide 8

Slide 8 text

Slide 9

Slide 9 text

導入篇

Slide 10

Slide 10 text

Slide 11

Slide 11 text

● PJ開始当初から以下の条件のもとで進める必要があった ○ スコープが広い ○ ほぼ確定した納期がある ○ スクラムを組んでイテレーティブな開発を行う ○ 他PJとの兼ね合いで潤沢なQAリソースは見込めない © Money Forward, Inc. どのように品質保証を進めるか？〜前提〜

Slide 12

Slide 12 text

● できるだけ前工程でバグを潰す ○ 要件やデザインのレビューを行い、他機能との関連性やデザインの統一性などを確認 ● 不具合の資産化 ○ 不具合情報を資産として残せるよう、不具合管理を継続して行う © Money Forward, Inc. どのように品質保証を進めるか？〜作戦1〜

Slide 13

Slide 13 text

● QAチェックを効率よく効果的に行う工夫 ○ スコープ、デリバリー、QAEリソースを加味して、実装が完了した機能に対して受入基準ベースの探索的テストを実行する ○ 探索的テストの内容を自動化し、後続のSprintでリグレッションテストとして実行できるようにするのがQCDのバランス的に最善だと考えた ○ QAEリソースに余裕ができた場合は積極的にリソースを投入し、いろんな視点でのチェックを行う © Money Forward, Inc. どのように品質保証を進めるか？〜作戦2〜

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● Must ○ 使いやすいフレームワークであること ○ 開発が継続して行われていること、ドキュメントが整っていること ○ テスト結果をわかりやすく集計してくれること ○ 各種CIツールで利用できること ● Need ○ テストケースが直感的に書けること ○ 誰でも書けること ● Want ○ Spec/Stepの概念があると嬉しい、SpecがMarkdownなどで書けると嬉しい ○ 日本語が使えると嬉しい © Money Forward, Inc. 自動E2Eテスト導入まで道のり〜選定条件〜

Slide 16

Slide 16 text

条件に合致した gauge+TAIKO を採用することに決定！ © Money Forward, Inc. 自動E2Eテスト導入まで道のり〜採用〜参照：gauge.org 

Slide 17

Slide 17 text

© Money Forward, Inc. ● https://gauge.org/ ● SpecがMarkdown形式で書ける ● 実装部分は複数言語サポート ○ 確定申告ではjsを採用 ● https://taiko.dev/ ● Chromiumベースの自動テスト用API ● Gaugeとセットで利用することが推奨されているメリット ● Markdown形式のためレビューしやすい ● taiko APIを利用することで、エンジニア経験が浅いメンバーでも実装が可能 ● GitHubでソース管理しているため、Sprintごとの差分やレビュー記録が参照しやすい gaugeとTAIKOについてちょっと紹介

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● gauge+TAIKO+Headless Chrome（以降同じ） ● 自分の業務用Macbook Pro 1台 ● ケースが少なかったので直列で実行していた ● 実行時間は30分くらい © Money Forward, Inc. 実行環境〜導入初期〜

Slide 20

Slide 20 text

© Money Forward, Inc. 実行環境〜導入中期〜 ● 導入中期前半 ○ 直列で1時間半位かかるようになってきた ■ →並列化（8並列） ○ まだ自分の業務用Macbook Pro 1台 ● 導入中期後半 ○ さらにケースが増えて3時間位 ■ →クラウドサーバに環境構築 ○ と自分の業務用Macbook Pro 1台 ○ 重要度の低いテストケースを実行対象外に ○ 各8並列の計16並列で2時間くらい

Slide 21

Slide 21 text

● クラウドサーバのメモリを増強して、全てクラウドサーバ上で処理できるようにした ● Jenkinsからキックできるようにした ● 20並列で大体1時間15分位 ● 30分位かかるSpecがある ○ 並列数を増やしてみたりした ■ これ以上並列化しても時間短縮は見込めず © Money Forward, Inc. 実行環境〜導入後期〜 jenkins.io 

Slide 22

Slide 22 text

● 一人で対応していたので辛かった... ○ 1Sprint 2week ■ 1Sprintの前半に探索的テスト ■ 1Sprintの後半に自動E2Eテストの実装 ○ 加えて、グループリーダー業務＋プロジェクト掛け持ち ● 時間に追われてドキュメントを残せていなかった... ○ mayaさんごめんなさい © Money Forward, Inc. 困ったこと・課題〜その1〜

Slide 23

Slide 23 text

● 取りきれない不具合はもちろん存在した... ● ランダムフェイルが多い... ● クロスブラウザの対応ができなかった...（Chromeのみ） © Money Forward, Inc. 困ったこと・課題〜その2〜

Slide 24

Slide 24 text

● 0→1フェーズだからという理由で困ったことはない（と思う） ○ 最初に目的や方針を明確にしていたのが良かったかも ■ 作るケースの粒度があまりブレなかった ○ Sprint 0でインセプションデッキやユーザーストーリーマッピングの構築に参加できたのも良かったかも ■ プロダクトが目指している姿の解像度が高かった ○ テスト実装の前に要件やデザインのレビューができていたのも良かったかも ■ テスト観点の整理が早い段階でできた © Money Forward, Inc. 良かったこと〜その1〜

Slide 25

Slide 25 text

● やりきれたこと ● gauge+TAIKOだからという理由で困ったことはない ● SpecがMarkDownで残るのから超Good ● 新機能実装時に既存機能の手動リグレッションテストの工数をだいぶ省ける ● 自動テストの動作確認時にもう一回機能のチェックができる © Money Forward, Inc. 良かったこと〜その2〜

Slide 26

Slide 26 text

● 個人的には0→1フェーズでE2Eテストの自動化に取り組むのも悪くないなと思った ○ 正直めちゃめちゃうまく行ったとは思ってない ○ 変更が頻繁に入るプロダクトやプロジェクトだともっとつらみが凄そう ○ QAEのプロダクトやプロジェクトへの関わり方によっても変わってきそう © Money Forward, Inc. 導入篇まとめプロダクトやプロジェクトの性質、払えるコスト、スケジュールなどから適切に判断する必要がありそう

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 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週間となっていた

Slide 30

Slide 30 text

© Money Forward, Inc. 背景：実は結構難しい、確定申告という仕組み入出力のパターンがかなり多い ● そもそも項目が多い ○ 画面数も所得の種類などに合わせて多くなっていた ● 複数の閾値が絡み合う ○ 年齢や所得額によって異なる計算式 ○ 所得の種類も複数 ● 法令の絶妙な言い回し ○ 合計所得金額 ≠ 総所得金額等 ≠ 総所得金額分離課税と損失申告 (2021年のマイルストーン) ● 同じ名前の所得でもケースによって異なる課税形式 (ex. 上場株式等の配当等) ● 所得金額の再計算が入るため、計算式も難易度UP (参考) 令和3年分所得税及び復興特別所得税の手引き(確定申告書B用)

Slide 31

Slide 31 text

© Money Forward, Inc. ● 複数のフィーチャーチームに分かれたことで爆増したスクラムイベント ○ QAがスクラムイベントの参加を減らすことによるリスクはこれまでの経験で理解していた ○ というわけで、全部参加 ■ 更に当初、リファインメントが PO<->開発と PO<->デザイナーの2セットあった ■ それぞれのスクラムイベントが長時間になりがち ● これは半年後くらいに解消されるが、それはまた別のお話早速キャパオーバー

Slide 32

Slide 32 text

© Money Forward, Inc. ● 「QAさんのテストやレビューがOKにならないとDoneにならないんです」 ○ (QAが当たり前に開発フローの中に入っているのはありがたい話だと思いつつ) ○ そもそもこれまでの1年分の仕様やその背景を知らない状態からのスタート ■ 前年のプロダクトバックログアイテム(PBI)と国税庁のページを都度検索しながらのテスト ■ Sprint前半はデザインレビュー、後半は仕様書レビューと探索的テスト ● じっくり仕様を理解する時間が取りにくい ○ 次Sprintに持ち越してしまうPBIが徐々に増えていった… 早速キャパオーバー

Slide 33

Slide 33 text

© Money Forward, Inc. そしてE2E自動テストはどうなったか ● 慣れるまでは西條さんが実行とメンテを担当するということで合意していたが…… ○ 結局余裕の無いまま、3ヶ月くらいお願いすることに ● E2E自動テストの中でどんなシナリオが実行されて、何が担保されているのかほとんどわからない、ブラックボックス状態が続いた ○ すでにシナリオは400件近くある ○ それぞれのシナリオの意図を読み解くのが難しい内容になっていた ■ 「なんでこの入力でこの出力結果になるんだろう？」「なんでこの表示をチェックしている(or していない)んだろう？」 → 根拠となる計算式やPBIを探し出すのに1〜2時間…

Slide 34

Slide 34 text

© Money Forward, Inc. ● 新規画面のシナリオを作る余裕がない ● シナリオ修正もひとりで抱え込むことに ○ QAチームの他のメンバーは開発未経験 ■ 教える余裕がない ■ 何から教えればいいのか考える余裕もない ● その結果 ○ 深夜までシナリオ修正する日が度々発生していた ○ 「E2E自動テストで何がテストされているのかわからない」というチーム内での不満が溜まっていくのを感じる実装・実行も引き継いだが…… JSの構文を見せても伝わるかな… Gitはコマンド教えるだじゃダメだよね…

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© Money Forward, Inc. ● いつ、何のPBIによって発生したシナリオ修正なのかコミットログやPRに残る ○ シナリオの意図が第3者からも掴みやすい ● 複数人でコードを触ると何が起きるか、というのを身をもって体験できる ○ なぜブランチを作成する必要があるのか ○ なぜデグレやコンフリクトが発生するのか ○ ここから開発者の気持ちを考えるきっかけになる GitHub を使うことによる副次的な効果

Slide 39

Slide 39 text

© Money Forward, Inc. ● 「ノーコードの自動テストツールに乗り換えることも検討した方がいい」と西條さんに言われたことがあったが、その選択は取らなかった ● 実装経験を積む機会を回避させることが最善だとは思えなかった ○ E2Eテスト以外にも、ノーコードではないツールを使ってみたい・作ってみたいというタイミングは必ずどこかで出てくる ○ どこかで一歩目を踏み出さないと、可能性は広がらない ● ここでやれなかったら、どこでやるの？ ○ 一番挫折しがちな環境構築は済んでいて、運用もしている ○ 少なくとも今1人、教えられる開発経験者がいる(＝私) Gaugeを使い続ける理由 (1)

Slide 40

Slide 40 text

© Money Forward, Inc. ● テキストベースでシナリオを記述できる強み ○ コメントを柔軟に残しやすい ■ 最近は途中計算や背景となったPBIのリンクを手厚めに記載している ○ QA以外のメンバーに共有しやすい ■ シナリオの一部をSlackにコピー＆ペーストして挙動を相談することも ○ 差分の比較もしやすい ■ 毎年更新される様式と「5年前までさかのぼって申告できる」という要件 ■ プロダクトコードもE2Eテストのシナリオも、最大5つのバージョンを維持しなければならない Gaugeを使い続ける理由 (2)

Slide 41

Slide 41 text

© Money Forward, Inc. リニューアル版クラウド確定申告のリリースから約2年 ● これまでに作成されたPBI　2,000件以上 ● 複雑さゆえに重厚化していく要件と仕様ドキュメントを残すだけでは「現在どのように動作しているのか」という疑問や不安をカバーし続けるには限界があるだからこそ「具体的な入出力」を「ユーザーと同じふるまいで」メンテナンスし続ける「生きた手順書」が必要動き続ける、生きた手順書