VeriServe Test Automation Talk No.2 freee編 2022.03.17 freee 株式会社

2 2019年6月 freee株式会社へ入社 入社以来、自動テストやテスト環境など品質 改善に関する仕組みの開発や企画、日々の運 用をおこなっています。 並行して、品質に関するコンサルティングの 個人事業主や「ソフトウェアテスト自動化カ ンファレンス」の司会係のような社外活動も おこなっています。 今日はfreeeが日々利用・開発しているコード ベースの自動テストに関して、どのようなも ので、仮に今から私が自動テストをはじめる ならどうするかを紹介します。 teyamagu freee株式会社 プロダクト基盤本部 Software Engineer in Quality

3 01 freeeの紹介 02 freeeの自動テスト 03 なぜこのシステム構成か？ 04 今から始めるなら 05 おわりに アジェンダ

スモールビジネスを、 世界の主役に。

5 freee会計 freee開業 freee福利厚生 freeeアプリストア freee人事労務 freee会社設立 freeeスマート受発注 freeeプロジェクト管理 freee資金調達 freee申告 freeeカード プロダクトラインアップ

6 2021年前年比 +34.2 % 2013年 3月 2014年 3月 2015年 3月 2016年 3月 2018年 3月 2019年 3月 2020年 3月 2021年 3月 2017年 3月 有料課金ユーザー数は28万社を超える

7 01 freeeの紹介 02 freeeの自動テスト 03 なぜこのシステム構成か？ 04 今から始めるなら 05 おわりに アジェンダ

8 freeeの自動テスト ユニットテスト、APIテスト、ユースケースベースのEnd2Endテスト、様々な自動テストが社内では動いています。 提供形式としてはWEBとモバイルアプリがあり、それぞれの確認で自動テストを利用しています。 WEBでの目指す自動テストと量(2ｰ3年) メソッド・モジュール・クラ ス・コンポーネントが設計通り の挙動・DOMとなるか APIレスポンスやレポート計算な ど複数モジュールやクラスの動 作が設計通りの挙動となるか 表示が想定通りか ユースケースが実施できるか 責務 rspecのspec snapshotテスト APIベースのユースケーステスト 数値計算系のテスト public apiのテスト 表示の差分のテスト jestのテスト E2Eテスト ブラウザがないと 確認できないモノ

9 freeeの自動テスト ユニットテスト、APIテスト、ユースケースベースのEnd2Endテスト、様々な自動テストが社内では動いています。 提供形式としてはWEBとモバイルアプリがあり、それぞれの確認で自動テストを利用しています。 WEBでの目指す自動テストと量(2ｰ3年) メソッド・モジュール・クラ ス・コンポーネントが設計通り の挙動・DOMとなるか APIレスポンスやレポート計算な ど複数モジュールやクラスの動 作が設計通りの挙動となるか 表示が想定通りか ユースケースが実施できるか 責務 rspecのspec snapshotテスト APIベースのユースケーステスト 数値計算系のテスト public apiのテスト 表示の差分のテスト jestのテスト E2Eテスト ブラウザがないと 確認できないモノ 今日はこのE2Eテ ストについて話 をします

10 ・テストフレームワークとしては、rspec, Capybara, SitePrismをベースに独自サポートメソッド群などを追加したもの ・Capybaraはrubyでのselenium supportをおこなうOSS ・SitePrismはCapybaraでPageobjectパターンを簡単に実現するためのOSS ・テストスクリプトは、rspecをベースにした手続き型記述形式 ・全サービス共通のE2Eテストシステム freeeのWEBのE2Eテストシステムの現在の構成 EC2 EC2 slack 自家製slack bot Jenkins Master Allure テスト実行ノード 実行管理・レポートサーバ 実行指示サーバ BigQuery Redash EC2 Jenkins Node ruby Capybara SitePrism テスト シナリオ ページ オブジェクト サポート メソッド rspec EC2 Jenkins Node ruby Capybara SitePrism テスト シナリオ ページ オブジェクト サポート メソッド rspec EC2 Jenkins Node ruby Capybara SitePrism テスト シナリオ ページ オブジェクト サポート メソッド rspec EC2 Jenkins Node ruby Capybara SitePrism テスト シナリオ ページ オブジェクト サポート メソッド rspec TestRail

11 ・シナリオ数：600シナリオくらい ・月実行回数：のべ25000ファイルくらい(1ファイル2ｰ3シナリオ)(テスト環境に限定して) ・利用目的：主には、高頻度に発生するリリース前や大きめの機能追加時のリグレッションテストを遅滞なくおこなう ・実行維持コスト：各開発チームで基本おこなっているので正確ではないですが、 全サービス分合わせても毎日1人が対応したら十分維持できる程度 freeeのWEBの全サービスでのE2Eテストの規模感 2020 2019 (10月〜) 2021 2022 10万 20万 30万 テスト環境での年間実行回数 10/20-12/31の 実績から推定

12 01 freeeの紹介 02 freeeの自動テスト 03 なぜこのシステム構成か？ 04 今から始めるなら 05 おわりに アジェンダ

13 ・全社的な状況： ・今後も新規サービスは増えつつも、巨大なサービスがある状態も続く ・社内で開発チームメンバーは異動がそれなりに発生する ・サービスの特徴： ・ブラウザだと、各種ページとフロントコンポーネント、サーバサイドが変更点となる ・バックオフィス系サービスであり、あちこちのUIが頻繁に大きく変更はできない ・最終的な作成者・運用者： ・サービス開発チーム（プロダクトマネージャー、プログラマー、テスター） 「必要なテストはサービス開発している人たちによって作成・運用されることが一番無駄が少ない」 ・どの程度の利用となるか： ・頻繁な改修および提供を考えると、必ず高頻度となる freeeのWEBのE2Eテストをとりまく環境

14 ・全社的な状況： ・今後も新規サービスは増えつつも、巨大なサービスがある状態も続く ・社内で開発チームメンバーは異動がそれなりに発生する ・サービスの特徴： ・ブラウザだと、各種ページとフロントコンポーネント、サーバサイドが変更点となる ・バックオフィス系サービスであり、あちこちのUIが頻繁に大きく変更はできない ・最終的な作成者・運用者： ・サービス開発チーム（プロダクトマネージャー、プログラマー、テスター） 「必要なテストはサービス開発している人たちによって作成・運用されることが一番無駄が少ない」 ・どの程度の利用となるか： ・頻繁な改修および提供を考えると、必ず高頻度となる freeeのWEBのE2Eテストをとりまく環境

15 なぜこのシステム構成か？ その1 ・「今後も新規サービスは増えつつも、巨大なサービスがある状態も続く」 & 「社内で開発チームメンバーは異動がそれなりに発生する」 ⇒ 全社で共通的な基盤を利用した方が、メンバーの学習コストや全社的なテスト基盤運用のコスト低減が期待できる。 ・「頻繁な改修および提供を考えると、必ず高頻度となる」& 「今後も新規サービスは増えつつも、巨大なサービスがある状態も続く」 ⇒ 今だけ自動テストがあれば良いということはなく、継続的に利用していけ、かつ テストシナリオの増加と実行回数が増大するときにでも低コストで管理、運用ができる基盤である必要がある。 ・「各種ページとフロントコンポーネント、サーバサイドが変更点となる」＆ 「あちこちのUIが頻繁に大きく変更されない」 ⇒ テスト対象サービスの変更点としては、ページおよびコンポーネントの挙動が少し変更されることが多い。 & その変更点に合わせて、テストコードをピンポイントで変更できることが運用コストを下げるためには望まれる。 ⇒ レコード型のテスト作成・運用方法は選択しにくい。 (最近のレコード型のテスト作成ツールは、オートヒールやまとまりを定義できるようになってきていますが、 まだ物足りない）

16 ・「作成者・運用者はサービス開発チーム」& 「各種ページとフロントコンポーネント、サーバサイドが変更点となる」 ⇒ 社内の主要プログラミング言語はRubyであり、Capybara&SitePrismを利用すると テストシナリオはシンプルな手続き的な記述で定義できる。 また、Capybara&SitePrismを利用すると、大まかには変更点とファイルの対応づけができ、修正を局所化しやすい。 ・各種ページ ⇒ ページオブジェクト ・フロントコンポーネント ⇒ Section ・サーバサイド ⇒ テストシナリオ テストシナリオ例） なぜこのシステム構成か？ その2 scenario 'サインアップし、ホーム経由で取引登録画面まで遷移できるか確認する(個人、課金無し)' do @helpers.accounting.signup(plan: :trial) @app.accounting_index.header.navbar_menu.deal_link.hover @app.accounting_index.header.navbar_menu.deal_dropdown_menu.deal_link.click expect(@app.accounting_deals_index.header.deals_tab_menu.deal_link.text).to eq '取引（収入・支出）' end

17 01 freeeの紹介 02 freeeの自動テスト 03 なぜこのシステム構成か？ 04 今から始めるなら 05 おわりに アジェンダ

18 ・サービスが市場にまだ受け入れられていない状態 ⇒ 少量のテストをレコード型のテスト環境SaaSを利用して、素早く作り自動テストを始めます。 ・サービスがグロースするか不明な中で過剰な投資を避けつつ、自動テストの効果を得るため。 ・グロースしたらテスト基盤を変更することを事前に伝えておきます。 ・サービスがすでに十分に大きく、今後も成長していくことが予測されている状態 ⇒ 最低限実行したい頻度やテスト数、機能を確認し、最も単純なシナリオからコードベースの自動テストを始めます。 ・期待しているものが実現できないテストシステムを作っても意味ないため、期待である最低限実行したい頻度や テスト数、機能を確認します。 ・その上で、作って動かしてみないとわからないことも多い(運用コストや実際の変更頻度など)ので、 なるべく早く使っていきます。 ・仮に、テスト対象の自動テストシステムがなく、私がプログラミング出来ない状態なら ⇒ テスト対象を構成している言語で、プログラミングを勉強しつつ、 まずは少量のテストをレコード型のテスト環境SaaSを利用して、素早く作り自動テストを始めます。 出来上がった自動テストをちょっと書き換えるなどをしてみて、プログラミングをさらに学んでいくと思います。 今から始めるなら

19 01 freeeの紹介 02 freeeの自動テスト 03 なぜこのシステム構成か？ 04 今から始めるなら 05 おわりに アジェンダ

20 ・プログラミングを知りましょう。自動テストを作る際にも必要ですが、テストをうまくなるためにも必要です。 うまくある必要はありません。うまい人は隣にいるはずなので、その人に相談できる程度に知りましょう。 ・自動テストは、テスト対象の状態の変化にあわせて変化させていく必要があり、継続的な投資が必要なものです。 全く自動テストを実施していないのでしたら、自分が運用できる小さな範囲で始めることをお勧めします。 ・コードベースの自動テストは、手元で動かすくらいならコスト少なくできますが、 基盤を用意してまでおこなうには、CI/CDをおこなうような、それなりの利用頻度がないと メリットが少ないかなと思います。 ・逆に利用頻度やテストの量が多い場合は、実行回数課金系ツールはそれなりの費用を必要としますが、 コードベースの方がインフラ&メンテナンスコストを工夫で安くでき、メリットが出てくると思います。 おわりに

スモールビジネスを、世界の主役に。

22 サービス間APIのテストやアクセシビリティテスト、パフォーマンステストなど、E2Eテスト以外の自動テスト基盤や 効率的なテスト環境の整備など、やりたいことが山盛りです。 今回の話を聞いて、freeeでの品質改善に興味持ってくれた方いませんか！？ ちょっと話聞いてみたいくらいの人でもカジュアル面談できます。気軽に応募ください！ https://jobs.freee.co.jp/engineers/ ←の「SEQ（Software Engineer in Quality）」が我々のところです。 One moreなんとか