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

Reason for developing and operating code-based ...

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. 2 2019年6月 freee株式会社へ入社 入社以来、自動テストやテスト環境など品質 改善に関する仕組みの開発や企画、日々の運 用をおこなっています。 並行して、品質に関するコンサルティングの 個人事業主や「ソフトウェアテスト自動化カ ンファレンス」の司会係のような社外活動も おこなっています。

    今日はfreeeが日々利用・開発しているコード ベースの自動テストに関して、どのようなも ので、仮に今から私が自動テストをはじめる ならどうするかを紹介します。 teyamagu freee株式会社 プロダクト基盤本部 Software Engineer in Quality
  2. 6 2021年前年比 +34.2 % 2013年 3月 2014年 3月 2015年 3月

    2016年 3月 2018年 3月 2019年 3月 2020年 3月 2021年 3月 2017年 3月 有料課金ユーザー数は28万社を超える
  3. 9 freeeの自動テスト ユニットテスト、APIテスト、ユースケースベースのEnd2Endテスト、様々な自動テストが社内では動いています。 提供形式としてはWEBとモバイルアプリがあり、それぞれの確認で自動テストを利用しています。 WEBでの目指す自動テストと量(2ー3年) メソッド・モジュール・クラ ス・コンポーネントが設計通り の挙動・DOMとなるか APIレスポンスやレポート計算な ど複数モジュールやクラスの動

    作が設計通りの挙動となるか 表示が想定通りか ユースケースが実施できるか 責務 rspecのspec snapshotテスト APIベースのユースケーステスト 数値計算系のテスト public apiのテスト 表示の差分のテスト jestのテスト E2Eテスト ブラウザがないと 確認できないモノ 今日はこのE2Eテ ストについて話 をします
  4. 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
  5. 15 なぜこのシステム構成か? その1 ・「今後も新規サービスは増えつつも、巨大なサービスがある状態も続く」 & 「社内で開発チームメンバーは異動がそれなりに発生する」 ⇒ 全社で共通的な基盤を利用した方が、メンバーの学習コストや全社的なテスト基盤運用のコスト低減が期待できる。 ・「頻繁な改修および提供を考えると、必ず高頻度となる」& 「今後も新規サービスは増えつつも、巨大なサービスがある状態も続く」

    ⇒ 今だけ自動テストがあれば良いということはなく、継続的に利用していけ、かつ テストシナリオの増加と実行回数が増大するときにでも低コストで管理、運用ができる基盤である必要がある。 ・「各種ページとフロントコンポーネント、サーバサイドが変更点となる」& 「あちこちのUIが頻繁に大きく変更されない」 ⇒ テスト対象サービスの変更点としては、ページおよびコンポーネントの挙動が少し変更されることが多い。 & その変更点に合わせて、テストコードをピンポイントで変更できることが運用コストを下げるためには望まれる。 ⇒ レコード型のテスト作成・運用方法は選択しにくい。 (最近のレコード型のテスト作成ツールは、オートヒールやまとまりを定義できるようになってきていますが、 まだ物足りない)
  6. 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
  7. 18 ・サービスが市場にまだ受け入れられていない状態 ⇒ 少量のテストをレコード型のテスト環境SaaSを利用して、素早く作り自動テストを始めます。 ・サービスがグロースするか不明な中で過剰な投資を避けつつ、自動テストの効果を得るため。 ・グロースしたらテスト基盤を変更することを事前に伝えておきます。 ・サービスがすでに十分に大きく、今後も成長していくことが予測されている状態 ⇒ 最低限実行したい頻度やテスト数、機能を確認し、最も単純なシナリオからコードベースの自動テストを始めます。 ・期待しているものが実現できないテストシステムを作っても意味ないため、期待である最低限実行したい頻度や

    テスト数、機能を確認します。 ・その上で、作って動かしてみないとわからないことも多い(運用コストや実際の変更頻度など)ので、 なるべく早く使っていきます。 ・仮に、テスト対象の自動テストシステムがなく、私がプログラミング出来ない状態なら ⇒ テスト対象を構成している言語で、プログラミングを勉強しつつ、 まずは少量のテストをレコード型のテスト環境SaaSを利用して、素早く作り自動テストを始めます。 出来上がった自動テストをちょっと書き換えるなどをしてみて、プログラミングをさらに学んでいくと思います。 今から始めるなら