freee 株式会社 システムテスト自動化カンファレンス2018 前半 freeeの品質トゥギャザー 2018.12.08

2 2 freeeとQAの紹介 01 Section

Koichi Nishide 西出 皓一 3 2015年1月 freeeに入社 最初の2年間は人事労務freeeのエンジニアをし て、今はQAマネージャーをしています

4 創業からIPOまで、中小企業活性化のためのサービスを一気通貫で提供 freee会社概要 ❂ 納税する ↗ 育てる ↻ 運営する ✩ はじめる 会社設立 freee 開業 freee クラウド会計ソフト freee 人事労務 freee (マイナンバー管理 freee 含む) クラウド申告 freee 161億603万円 (資本準備金等含む) 従業員数 事業内容 クラウド型バックオフィスサービスの開発・販売 資本金 設立年月日 2012年7月 465名（2018年6月末時点） 2017年「働きがいのある会社」 ランキング3位

5 会計・給与共に法人シェアNo.1 * BCN調べ * MM総研調べ * 2017年8月より、クラウド給与計算ソフト freeeは、機能を強化し、新たに 「人事労務 freee」というサービス名に変更しました。 　 クラウド給与ソフト 市場 40% クラウド会計ソフト 市場 35.2%

6 6 利用事業所数累計 100万 2014.3 2015.3 2016.3 2017.3 2018.3 800,000 600,000 300,000 65,000 1,000,000 1,000,000

7 465人 従業員数 豊富な人員で、開発・導入支援・サポートを強化 freee従業員数推移 2013 2014 2015 2016 2018 2017年「働きがいのある会社」 ランキング3位 2017 2018年7月1日時点、アルバイト契約社員インターンを含む 業務委託、派遣、出向を含めると614名

8 QAチーム ● ミッション ○ 品質トゥギャザーでハッピー流出を防ぐ ● とにかくトゥギャザーが重要である ● ハッピーは不具合のこと ● やっていること ○ リスクを洗い出してテストする（プロダクトを知る） ○ テスト自動化 ○ 品質向上に関する施策・リファクタリング etc

9 言葉では伝わりにくいので トゥギャザー度の高そうな事例をいくつか紹介します

10 10 どういうハッピーが多いのかわからない問 題 02 Section

11 どんなハッピーが起きてるか、が見えずらい ● 当時のハッピーの集計にはいくつか課題があった ○ スプレッドシート上でGAS + 手動操作で集計していて、属人性が高かった ○ 時間もそれなりにかかる ■ 約30h / 1month ○ 集計したい項目を追加しづらい ● でも、現状の品質を知るために、起きてるハッピーをいろいろな角度でみたい ○ 機能別 ○ ユーザ種別 ○ 優先度別 ○ 残ハッピー数 ○ 作成数 vs 解消数 など

12 集計の自動化 ● よし、freee社内のデータ基盤にのせれば属人性なくなるぞ！、ということで下記の構成でいこうかと ● ゼロコスト ● sqlで集計できる ● ハッピー以外の情報もredashでみるのが社内標準だったので、アクセシビリティup ● 集計項目の拡張もコード書けば可能

13 そもそも、チケットの情報が正確とは言い難かった ● ハッピーチケットの運用フローが統一されてなかった ○ どっちがボール持ってるかわからないので、滞留ボトルネックがわからない ○ 優先度高と中の違いは？ ○ 似たような機能名があって、名寄せが必要、などなど → サポート、エンジニアチームとハッピー運用フローをゼロベースで作成 正確な情報得るためには、ハッピー運用フローから変えな いとだめだった

14 最終的に ● Google Formで起票情報の品質底上 ● チケット運用フローのアップデート ● JIRAへ移行 ○ 運用フローのシステム化ができる ○ サードパティ連携豊富

15 みんながハッピー分析できるようになってハッピー ここから進んだ品質改善プロジェクトもあります

16 16 複雑なドメインは複雑である問題 03 Section

17 複雑なドメインは複雑 給与計算 年末調整 勤怠 所得税徴収高

18 複雑なので専門家にテスト協力依頼した ● リスクや法律についてドメインスペシャリストの社労士さんや税理士さんに相談。リスク 洗い出し。 ● 具体的なテストケースの認識を合わせて、ドメインスペシャリストに期待値を計算しても らう ○ Googleスプレッドシート上でやりとり 事前条件、入力パラメータ 期待値

19 複雑で覚えられないので、spec化した 社労士さん csv APIテスト（request spec）で実装。PR 単位で実行。計算はAPIで完結できる ので、E2Eは使わない。 https://martinfowler.com/bliki/TestPyramid.html

20 ドメインスペシャリストのテストがCIで動いてるのは心強い スプレッドシートを見ればどういうケースが動いているかが見えるので、コード読めない人でも確認できるのも嬉し い。ただ、スプレッドシート地獄になりつつあるのが課題。

21 21 弊社のE2Eテストのびしろある問題 04 Section

22 現状のE2Eテスト その１ ● PRコミット→PRテストや静的解析がCircle CIでまわる→stagingにデプロイ→E2E(自動 実行)→開発者動作確認→productionデプロイ ● ほぼ毎日リリースしているので、E2E自動テストは必須 staging環境 production環境 development環境 （ローカル） 静的解析 Unit・Serviceテスト E2Eテスト integration環境 x N個 QAテスト用 リリース前の長期検証が 必要な場合に使う

23 現状のE2Eテスト その２ ● Rspec x SitePrism x Capybara x Selenium ● 構成の理由 ○ プロダクトがrailsなので、みんなrspecには慣れている ○ SitePrismはページオブジェクトパターンを簡単に使える ○ Capybaraはいい感じのDSLがある ● その他 ○ E2Eテストコードは各プロダクトのリポジトリにある ■ QAだけでなく、エンジニアも気軽に修正できるようにするため（ユニットテスト感覚） ○ どういう時にシナリオを足しているか ■ 新機能リリース後が多い ○ テストデータどうしてる？ ■ 秘伝のテストデータをもったアカウントを使ってるところもある ■ デモデータ事業所のバリエーションを増やしていくことで対応していきたい

24 課題 ● E2Eテストに実行環境の制限や属人性があるため、リリース手前でデグレに気づいた り、シナリオのメンテナンスが大変（自動E2Eテスト視点） ● プロジェクト数に対するテスト環境不足（手動E2Eテスト視点） ● マイクロサービス化によるテスト環境構築大変（エンジニアのレビュー視点）

25 後半に続く スライド

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