Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reason for developing and operating code-based automated E2E testing

Reason for developing and operating code-based automated E2E testing

VeriServe Test Automation Talk # 2 Presentation
"Reason for developing and operating code-based automated E2E testing"

teyamagu

March 17, 2022
Tweet

More Decks by teyamagu

Other Decks in Programming

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide