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

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

View Slide

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

View Slide

小林羊哉
(Kobayashi Maya / yoya)
@yoya_k
　
https://note.com/yoya_k
マネーフォワードクラウド確定申告
2代目QAリーダー
Markin’ Quality レギュラーメンバー
(1日目の懇親会ジャックしたチームです！)
経歴
● 2009〜2016　小売業向けシステム開発
● 2016〜2019　ブラウザゲーム開発
● 2019〜　マネーフォワード JOIN
　　　　　＆ QAエンジニアに転身

View Slide

本セッションでお話しするE2Eテストは
UIテストのことを指しています
はじめにおことわり
Unit Tests
Integration
Tests
UI
Tests

View Slide

みなさん
E2Eテストの自動化やってますか？
いつから
自動化をはじめましたか？
ノーコード？
ローコード？
順調？
難航中？
ローンチ前？
運用に
入ってから？

View Slide

リリースするまではUIの変更も多いだろうし、
やっぱり運用フェーズに入ってから
よく実行するテストケースを自動化するのが
定石じゃないですか？
そんなことないよ！！
ええっ！？
というのが今回のお話。

View Slide

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

View Slide

2013 2020 2021.06
リリース
フルリニューアルプロジェクト
2月キックオフ
11月リリース！
・・・・・・
本日の話の流れ
導入篇運用篇

View Slide

導入篇

View Slide

プロジェクトが動き出した時の様子は？
Sprint 0 期間：約2ヶ月
やったこと
PdM：
● ユーザーニーズの把握や要件まとめ（ペルソナ作成など）
チーム：
● インセプションデッキの作成
● ペルソナを元にしたワークショップに参加
● ユーザーストーリーマッピングをプロジェクト関係者全員で作成
QAE：
● どのように品質保証を進めるかを考える

View Slide

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

View Slide

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

View Slide

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

View Slide

● QAチェックを効率よく効果的に行う工夫
○ スコープ、デリバリー、QAEリソースを加味して、実装が完了した機能に対して
受入基準ベースの探索的テストを実行する
○ 探索的テストの内容を自動化し、後続のSprintでリグレッションテストとして
実行できるようにするのがQCDのバランス的に最善だと考えた
○ QAEリソースに余裕ができた場合は積極的にリソースを投入し、いろんな視点で
のチェックを行う
🔦自動E2Eテストの導入検
討はここから始まりました。

View Slide

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

View Slide

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

View Slide

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

View Slide

2020.5.7
初めて画面のテストをpushするまで
2020.3.5
PJ本格始動！
Specのない
初期構成をpush
2020.5.20
初めて画面の
テストをpush
・・・・・・
Sprint 0 の中盤〜 Sprint 2 Sprint 3 Sprint 4

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

運用篇

View Slide

怒涛の1stリリースを経て……
● いちプロジェクトだったチームは、個人事業主本部として独立へ
○ モバイルアプリ版の開発チームも合流
● QA組織も併せて再構築することに
○ 別プロジェクトに従事していた yoya に白羽の矢が立ったのだが……
noteリンクはこちら

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Gauge道場
開設します！！！
そして2021年末、決意した

View Slide

週に1回、60〜90分くらいのハンズオン
1. バージョン管理の基礎
2. GitHubの使い方
3. ローカルでGaugeを実行してみよう
4. モブプロで簡単なシナリオ実装
5. PRを出してみよう
6. ブランチの運用について
Gauge道場とは

View Slide

その結果……
みんなにはきっと難しいと
勝手に決めつけて
壁を作っていたんだな…
● 想定より1ヶ月前倒しでシナリオ実装が進んだ
● シナリオの修正が必要な箇所を
自主的にタスク化するようになった
● 手動テストの要否を既存のシナリオから
判断できるようになった
○ ＝負担が大幅に減った！
● なにより
メンバーの目が輝いてきた！！！

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

ご清聴ありがとうございました
QA Engineer 積極採用中です
まずはカジュアルにお話しましょう！

View Slide

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

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

yoya_k

More Decks by yoya_k

Other Decks in Technology

Featured

Transcript