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

Are your automated tests improving?

teyamagu
November 05, 2022

Are your automated tests improving?

「皆さんの自動テストは改善されていますか?」 in JaSST'22 Kyushu #jasstkyushu

teyamagu

November 05, 2022
Tweet

More Decks by teyamagu

Other Decks in Programming

Transcript

  1. 「皆さんの自動テストは改善されていますか?」
    JaSST'22 Kyushu
    2022.11.05
    freee 株式会社

    View full-size slide

  2. 2
    freeeの自動テストの全体構成や具体的なシステム構成に関しては、
    過去の資料も参考になりますので、参照頂けると嬉しいです。
    今日の話に関連する情報
    https://developers.freee.co.jp/entry/auto
    mated-test-structure-2022
    https://speakerdeck.com/teyamagu/reason-for-developing-and-
    operating-code-based-automated-e2e-testing

    View full-size slide

  3. 3
    これから自動テストをはじめる方へ
    ・自動テストの運用としておこなうことの一例を知れます
    すでに自動テストをおこなっている方へ
    ・自動テストを運用していくなかでの改善点やその解決策の一例を知れます
    ・自動テストを来週から改善していく際のヒントを得られます
    今日の持ち帰り

    View full-size slide

  4. 4
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  5. 5
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  6. 6
    freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、
    統合型経営プラットフォームを開発・提供し、
    だれもが自由に自然体で経営できる環境をつくっていきます。
    起業やビジネスを育てていくことを、もっと魅力的で気軽な行為に。
    個人事業や中小企業などのスモールビジネスに携わるすべての人が、
    じぶんらしく自信をもって経営できるように。
    大胆にスピード感をもってアイデアを具現化できるスモールビジネスは、
    今までにない多様な価値観や生き方、
    新しいイノベーションを生み出す起爆剤だと私たちは考えています。
    スモールビジネスが大企業を刺激し、社会をさらにオモシロク、
    世の中全体をより良くする流れを後押ししていきます。
    Misson
    スモールビジネスを、世界の主役に。

    View full-size slide

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

    View full-size slide

  8. ※(1)2022年6月末時点の有料課金ユーザー数。有料課金ユーザー企業数には個人事業主を含む。またfreeeグループ全体で集計。
    2019年
    6月期
    2020年
    6月期
    2017年
    6月期
    2018年
    6月期
    2021年
    6月期
    有料課金ユーザー
    企業数(件)
    有料課金ユーザー企業数(1)は
    約38万
    事業所
    8.3万
    12.1万
    22.4万
    29.3万
    16万
    37.9万
    2022年
    6月期

    View full-size slide

  9. 9
    freeeの自動テストの背景
    ・多サービスかつ、今後も新規サービスは増えつつも、巨大なサービスがある状態も続く
    ・開発チームメンバーの異動や増加がそれなりに発生する
    ・高頻度のリリースのニーズが存在する

    View full-size slide

  10. 10
    freeeの自動テストの目的
    継続的に開発しているため、リグレッションテストが欠かせない。
    ただし、頻繁にお客様へ提供したい。
    頻繁におこなわれるリリースに対して、リグレッションテストを極力短時間で実施する。
    これは人力では困難であるため、自動実行されるリグレッションテストで実現する。
    この自動実行されるリグレッションテストを、本講演では「自動テスト」と呼びます。

    View full-size slide

  11. 11
    freeeの開発における自動テストの基本的な使い方
    基本的な使い方
    ・開発中に、開発者による開発環境でのコマンド実行
    ・各Pull Requestのコード更新時の自動実行
    ・テスト環境デプロイ前後の自動実行
    ・リリースワークフローでの自動実行
    なお、テストスクリプトの作成や修正、運用は、プロダクトマネジャー、プログラマー、
    テスト・QA担当者で構成される開発チームでおこなうものとしている

    View full-size slide

  12. 12
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  13. 13
    freeeの自動テスト
    ユニットテスト、APIテスト、ユースケースベースのEnd2Endテスト、様々な自動テストが社内では動いている
    freeeのサービスの提供形式としてはWEBとモバイルアプリがあり、それぞれの確認で自動テストを利用している
    下記以外に、セキュリティやアクセシビリティのテストなどが半自動で実施されている
    目指す自動テストと量
    メソッド・モジュール・クラ
    ス・コンポーネントが設計通り
    の挙動・DOMとなるか
    APIレスポンスやレポート計算な
    ど複数モジュールやクラスの動
    作が設計通りの挙動となるか
    表示が想定通りか
    ユースケースが実施できるか
    責務
    言語が持つテスト
    フレームワークでのテスト
    snapshotテスト
    APIベースのユースケーステスト
    数値計算系のテスト
    apiのテスト
    表示の差分のテスト
    jestのテスト
    E2Eテスト
    ユニットテスト
    E2Eテスト
    今回の講演での呼び名
    APIテスト

    View full-size slide

  14. 14
    Jenkins Node
    Ruby
    テスト
    シナリオ
    ページ
    オブジェクト
    サポート
    メソッド
    RSpec
    EC2
    Jenkins Node
    Ruby
    テスト
    シナリオ
    ページ
    オブジェクト
    サポート
    メソッド
    RSpec
    EC2
    ・テストフレームワークとしては、プログラミング言語のユニットテストフレームワークや
    パッケージ(RSpec, golang testing, Jestなど)
    ・各サービスごとのシステムだが、基本的には開発環境とCircleCI, GitHub Actionsで動いている
    freeeのユニットテストシステムの現在の構成
    Rubyのテスト実行ノード
    CircleCI /
    Github Selfhosted runner
    Docker
    Ruby
    テスト対象
    コード
    テスト
    シナリオ
    サポート
    メソッド
    RSpec

    View full-size slide

  15. 15
    ・テストフレームワークとしては、RSpec, Capybara, SitePrismをベースに独自サポートメソッド群などを追加したもの
    ・CapybaraはRubyでのSelenium supportをおこなうOSS
    ・SitePrismはCapybaraでページオブジェクトパターンを簡単に実現するための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

  16. 16
    ・利用サービスとシナリオ数:約20サービス、600シナリオ以上
    ・月実行回数:のべ25000ファイルくらい(1ファイル2ー3シナリオ)(テスト環境に限定して)
    ・実行維持コスト:各開発チームで基本おこなっているので正確ではないですが、
    全サービス分合わせても毎日1人が対応したら十分維持できる程度
    freeeのWEBの全サービスでのE2Eテストの規模感
    2020
    2019
    (10月〜)
    2021 2022
    10万
    20万
    30万
    テスト環境での年間実行回数
    (2022年分は2月頃までの数字)
    10/20-12/31の
    実績から推定

    View full-size slide

  17. 17
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  18. 18
    自動テストを提供するチームとして、以下のことをおこなっている
    ・自動テストの実行失敗時の要因分析
    ・自動テストの実行環境のアップデート
    ・自動テスト実行時間の適正化に向けたテストスクリプトや構成の変更
    ・自動テスト利用者の拡大のサポート
    ・運用の改善
    自動テストの運用としておこなっていること

    View full-size slide

  19. 19
    自動テストの運用:自動テストの実行失敗時の要因分析
    自動テストの実行失敗時の要因
    ・テスト対象に不具合がある
    ・自動テストスクリプトがテスト対象の変更に追従できていない
    ・実行の不安定性
    そこで、具体的におこなっていることとしては以下の4つ
    ・失敗箇所の特定
    ・原因の推測
    ・自動テストの再実行
    ・失敗箇所に関する変更の確認

    View full-size slide

  20. 20
    自動テストの運用:自動テストの実行環境のアップデート
    ・テストフレームワークにおける利用ライブラリのアップデート
    ・自動テストの実行環境のOSのアップデートやセキュリティ対応
    ・利用ブラウザのアップデート
    ・アップデートによりテストに影響がないか検証、および影響発生時の対応

    View full-size slide

  21. 21
    自動テストが増えた場合、そのままでは実行時間が長くなる。
    頻繁に実行できるように、自動テスト実行時間を一定の時間内におさめる。
    そこで、具体的におこなっていることとしては以下の3つ
    ・時間のかかっているテストや処理の特定
    ・並列実行の構成変更
    ・自動テストスクリプトや自動テストシステムの
    不要な処理の削除や統合
    自動テストの運用:自動テスト実行時間の適正化
    週次のテストの平均・最大実行時間

    View full-size slide

  22. 22
    情報伝達の無駄の削減や自動テストの効果を最大化するために、
    自動テストはできる限り多くの人に利用して貰いたい。
    自動テストの利用者が社内で増えるよう、自動テストの利用サポートをおこなっている。
    具体的におこなっていることとしては以下の3つ
    ・テストスクリプト作成時、不安な方とのペア作業やコードレビュー
    ・初めて利用する人向けのドキュメントやコードスタイルガイドの提供
    ・機能改善や利用状況の社内PR
    自動テストの運用:自動テスト利用者の拡大のサポート

    View full-size slide

  23. 23
    利用者が利用を開始するようになるまで
    1.自動テストの効果を開発チームが理解するまで、価値を示し続ける
    ・自動テストで不具合が検知され、その不具合のインパクトが大きければ、
    そしてそれが度々発生すれば、自動テストの価値は理解される
    2.開発チームによる自動テストの利用・作成・修正する手間を1.の価値より低くする
    ・テストフレームワークの選択や様々な改善により手間を低くする
    利用者が利用を継続していく
    ・必要なら継続する。使われなくなったら削除する
    ・メンテナンスされなくなったり、修正できないようであれば、そのテストの要不要の話し合いを
    おこない、必要であればチームにスキルをつけて貰うようにサポートし、不要なら削除する
    上記に共通して、開始・継続する機会を逃さず提案・協働する
    (運用の話から脱線)自動テスト利用拡大に向けた考え方

    View full-size slide

  24. 24
    自動テストの運用:運用の改善
    ・テスト実行を安定化させる
    ・テストへの信頼向上と、再実行の無駄を削除する
    ・テストスクリプトを作成しやすく、修正しやすくする
    ・利用者を拡大しやすくし、要因分析およびその後の修正を時間を短くする
    ・運用の各作業を容易化・自動化する
    ・無駄な作業を削除する

    View full-size slide

  25. 25
    E2Eテストでは、現在は経験的に全体のテスト成功率が93−94%を下回ってきたら、
    また、個々のテスト成功率が5−10ポイント程度下がってきたら確認するようにしている
    自動テストの運用の改善:テスト実行の安定化
    ある1週間内でのE2Eテスト失敗率ベスト20の上位
    週次のテスト実行数と成功率

    View full-size slide

  26. 26
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  27. 27
    自動テストの改善で意識していること
    ・利用者が増え、利用されることを第一の目標とする
    ・そのために、安定化・高速化・低い学習コストの仕掛けの構築、などをおこなう
    ・利用の当事者であり続ける
    ・運用の改善は無駄の削除だけでなく、利用者の精神的な苦痛の排除も視野に入れる
    ・シンプルな状態を保つ
    ・長く使う道具であり、突発的なことへの対応も期待されるので、シンプルな状態を保

    View full-size slide

  28. 28
    1.利用者が自動テストを信頼して、利用できる基本を整える
    ・安定して利用できる
    ・待てる程度の実行時間で自動テストが終わる
    2.持続的に運用できる状態を維持する
    ・運用の手間がかかる部分を解消する
    3.利用者が自動テストを利用・作成・修正するための障壁を取り除く
    ・作成・修正しやすい環境を提供する
    ・利用しやすくする
    ・情報の拡充
    自動テストの改善の優先順位:基本的な考え方

    View full-size slide

  29. 29
    短期的な改善の視点と長期的な改善の視点の両方を持って改善に取り組んでいる
    短期的な視点で考えること:現テストシステムにおける各種改善
    ・基本的な考え方で記載の順
    ・なお、運用の手間がかかる部分の解消は、基本的に運用担当者のアイデアを生かす
    ・ペインを一番体感しているから
    長期的な視点で考えること:テストシステムの刷新・追加
    1.より利用者にとって使いやすいテストシステム
    2.テスト実行時間の大きな改善
    3.根本的な運用しにくさの解消
    (別軸)手動では現実的にはできないが、確認できると効果があるテストの自動化
    自動テストの改善の優先順位:短期・長期での考え方

    View full-size slide

  30. 30
    ・2012/7 (開発初期) 頃: RSpecのみ
    ・2014/10 頃: Jenkins 第1世代
    ・2017/10 頃: Jenkins 第2世代(Jenkinsfile化)
    ・2017/12 頃: CircleCI(多並列化)
    ユニットテストの運用と改善の概要
    いくつかのサービスのユニットテストおよび
    APIテストのファイル数

    View full-size slide

  31. 31
    ・2012/7 (開発初期) 頃: RSpecのみ
    ・開発環境での実施、1環境内ので並列実行
    ・運用内容
    ・実行失敗の要因分析
    ・ライブラリのアップデート
    ・ときどき改善
    ユニットテストの運用と改善(1)

    View full-size slide

  32. 32
    ユニットテストの運用と改善(2)
    ・2014/10 頃: Jenkins 第1世代
    ・運用内容
    ・実行失敗の要因分析
    ・実行環境のアップデート
    ・実行時間の適正化
    ・改善内容
    ・並列実行による自動テスト実行の高速化
    ・自分のPC以外でのテスト実行が可能になった
    ・実行環境と実行方法の追加:
    ・各Pull Requestのコード更新時の手動実行
    ・Jenkinsからテスト環境デプロイ前やリリースプロセスで手動実施

    View full-size slide

  33. 33
    ユニットテストの運用と改善(3)
    ・2017/10 頃: Jenkins 第2世代
    ・改善内容
    ・実行環境の運用の改善:設定のファイル化
    ・2017/12 頃: CircleCI
    ・改善内容
    ・実行方法の追加:
    ・各Pull Requestのコード更新時の手動実行
    ・実行環境の運用の改善:実行環境のIaC化
    ・実行時間の適正化:多コンテナ実行

    View full-size slide

  34. 34
    ・運用内容
    ・実行失敗時の要因分析
    ・ライブラリのアップデート
    ・ときどき改善
    ・改善内容
    ・基本的には実行時間の適正化
    ・無駄な前処理の削除
    ・並列実行の改善
    ・同一コンテナ内でのマルチプロセス実行
    ・実行の動的変更、動きの遅い実行環境での実行を回避する:Knapsackの導入
    ・確認の効率化
    ・テスト実行を安定化させる
    ユニットテストの運用と改善(4):その他

    View full-size slide

  35. 35
    ・2012/7 (開発初期) 頃: Request spec
    ・2019/9 頃: 会計帳簿計算用テストシステム稼働
    ・2020/5 頃: Postman
    ・2020/11 頃: NewmanとJenkins での自動実行
    APIテストの運用と改善の概要

    View full-size slide

  36. 36
    ・2012/7 (開発初期) 頃: Request spec
    ・以降、ユニットテストフレームワークを利用したAPIテストは、
    ユニットテスト同様の運用と改善が適用される
    APIテストの運用と改善(1)

    View full-size slide

  37. 37
    ・2019/9 頃: 会計帳簿計算用テストシステム稼働
    ・会計帳簿計算での不具合が発生したものの、手動では確認箇所が多過ぎて
    現実的には確認できないため、自動テストでの実現が求められた
    ・設定が書かれたスプレッドシートから、APIを呼び出すユニットテスト形式の
    テストコードを生成し、リリースプロセスで実行する
    ・運用内容
    ・ユニットテスト同様の運用
    ・改善内容
    ・新たなテストができるように専用自動テストシステムを開発
    ・複数の開発者とSEQ担当者による作成・運用
    APIテストの運用と改善(2)

    View full-size slide

  38. 38
    ・2020/5 頃: Postman
    ・手元PCからテスト環境デプロイ後に手動実施
    ・運用内容
    ・実行失敗の要因分析
    ・改善内容
    ・APIのシナリオテストができるようにツールを導入
    ・1名のQA担当者による作成・運用
    APIテストの運用と改善(3)

    View full-size slide

  39. 39
    APIテストの運用と改善(4)
    ・2020/11 頃: NewmanとJenkins での自動実行
    ・運用内容
    ・実行失敗の要因分析
    ・実行環境のアップデート
    ・実行時間の適正化
    ・改善内容
    ・並列実行による自動テスト実行の高速化
    ・自分のPC以外でのテスト実行が可能になった
    ・実行環境と実行方法の追加:
    ・Jenkinsからテスト環境デプロイ後やリリースプロセスで手動実施
    ・特定のQA担当者以外でもSlackからの実行可能に
    ・複数のQA担当者とSEQ担当者による作成・運用

    View full-size slide

  40. 40
    ・2014/9 頃: Selenium IDEによるテストシステム
    ・2015/2 頃: RubyのWebDriverによるテストシステム
    ・2016 頃: RubyのWebDriverのJenkins実行
    ・2016/6 頃: chatbotの導入
    ・2017/10から段階的に: Jenkinsでの連携実行
    ・2017/11 頃: Capybara+SitePrismによるテストシステム(1サービスごと)
    ・2019/9 頃: 結果の独自Slack通知
    ・2019/10 頃: E2Eテストの実行結果のデータ基盤への格納・可視化
    ・2019/12頃から段階的に: Capybara+SitePrismの全サービス共通構成によるテストシステム
    ・2020/2 頃: URLとページオブジェクトの構造とオブジェクト名の同一化
    ・2020/11頃から段階的に: 開発チームによるテストの運用
    ・2021/5 頃: レコード&リプレイ型の自動テストSaaSの併用開始
    ・2021/11 頃: Slackからの実行結果をスレッドに表示させる
    ・開発中: Pull Request上でE2Eテスト実行
    WEBのE2Eテストの運用と改善の概要
    統合したWEBのE2Eテストリポジトリにお
    けるテストファイル数とサービス数

    View full-size slide

  41. 41
    ・2014/9 頃: Selenium IDE(レコード&リプレイ型のツール)によるテストシステム
    ・手元PCからテスト環境デプロイ後に手動実施
    ・運用内容
    ・実行失敗の要因分析
    ・自動テストシナリオや利用サービス数:1サービスのみで導入。徐々にシナリオ増加
    ・1名のQA担当者による作成・運用
    WEBのE2Eテストの運用と改善(1)

    View full-size slide

  42. 42
    ・2015/2 頃: RubyのWebDriverによるテストシステム
    ・コードベースのテストシステムを導入
    ・運用内容
    ・実行失敗の要因分析
    ・ライブラリのアップデート
    ・改善内容
    ・複数人数で作成やレビューできるようになった
    ・自動テストシナリオや利用サービス数:
    ・2サービスから徐々に増え、最終的には5サービスで実施。シナリオも徐々に増加
    ・徐々にメンバー増加。3名程度のQA担当者が片手間で作成・運用するようになった
    WEBのE2Eテストの運用と改善(2)

    View full-size slide

  43. 43
    ・2016 頃: RubyのWebDriverのJenkins実行
    ・運用内容
    ・実行失敗の要因分析
    ・自動テストの実行環境のアップデート
    ・自動テスト実行時間の適正化
    ・改善内容
    ・並列実行による自動テスト実行の高速化
    ・自分のPC以外でのテスト実行が可能になった
    ・QA担当者以外でのテスト実行が可能になった
    ・実行環境と実行方法の追加:
    Jenkinsからテスト環境デプロイ後やリリースプロセスで手動実施
    WEBのE2Eテストの運用と改善(3)

    View full-size slide

  44. 44
    ・2016/6 頃: chatbotの導入
    ・改善内容
    ・実行方法の追加:Slackからのテスト実行開始が可能になった
    ・全ての人によるテスト実行が容易になった
    ・再実行までの時間が短くなった
    ・2017/10から段階的に: Jenkinsでの連携実行
    ・改善内容
    ・実行方法の変更:テスト環境デプロイ後やリリースプロセスで自動実施
    ・リリース前に実施忘れがなくなり、作業をなくすることができた
    WEBのE2Eテストの運用と改善(4)

    View full-size slide

  45. 45
    ・2017/11 頃: Capybara+SitePrismによるテストシステム
    ・Ruby開発者が慣れているテストフレームワークを導入
    ・運用内容
    ・実行失敗の要因分析
    ・ライブラリのアップデート
    ・改善内容
    ・開発者による作成・修正などができるようになった
    ・テストシナリオとページファイルの分離により、テストの作成・修正が容易化
    ・自動テストシナリオや利用サービス数:
    ・1つのサービスから導入開始し、最終的に2サービスで導入。シナリオは徐々に増加
    ・RubyのWebDriverのテストシステムで動作していたサービスはそのまま
    ・数名の開発者とQA担当者が作成・運用するようになった
    WEBのE2Eテストの運用と改善(5)

    View full-size slide

  46. 46
    WEBのE2Eテストの改善の背景(2019〜)
    E2Eテストに関しては2019年後半くらいから、テストの実行回数
    が増え、運用の作業量が増大したため、運用コストを大きく下げ
    る改善と開発チームを巻き込むための運用改善を重視した。
    ・大きな運用コストを生んでいた課題:
    ・複数のE2Eテストシステムと複数リポジトリの運用
    ・開発チームにとっての障壁:
    ・利用方法や作成に関する情報が不足していた
    ・低い成功率のため要因分析が高頻度で発生していた

    View full-size slide

  47. 47
    ・2019/9 頃: 結果の独自Slack通知
    ・改善内容
    ・実行失敗時の要因分析の高速化:
    ・失敗した際のテストのスタックトレースやスクリーンショットが
    2クリックで見られるようになった
    WEBのE2Eテストの運用と改善(6)

    View full-size slide

  48. 48
    ・2019/10 頃: E2Eテストの実行結果のデータ基盤への格納・可視化
    ・2016/9頃から2017/11頃も格納されていたが利用されず停止していた
    ・改善内容
    ・不安定なE2Eテストやサービスを、実行状況を週次や月次などの視点から
    把握、改善できるようになった
    WEBのE2Eテストの運用と改善(7)
    週次のテスト実行数と成功率
    週次のテストの平均・最大実行時間

    View full-size slide

  49. 49
    ・2019/12頃から段階的に: Capybara+SitePrismの全サービス共通構成
    によるテストシナリオ(現行の基本システム)
    ・運用内容
    ・実行失敗の要因分析
    ・ライブラリ・実行環境のアップデート
    ・実行時間の適正化
    ・改善内容
    ・全サービスで、同一の使い方や、テスト作成・修正が可能になった
    ・運用すべき箇所が1つに統合されたため、運用コストを下げられ、
    改善も一括提供できるようになった。
    ・人員およびその構成:1名のSEQ担当者と3名のアルバイトで運用開始
    WEBのE2Eテストの運用と改善(8)

    View full-size slide

  50. 50
    ・2020/2 頃: URLとページファイルのディレクトリ構造とオブジェクト名の同一化
    ・改善内容
    ・テストシナリオの作成・読みやすさの向上
    WEBのE2Eテストの運用と改善(9)
    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
    テストシナリオ例:改善前)
    テストシナリオ例:改善後)
    @app.{URL}.要素名.処理 で記述する
    scenario 'サインアップし、ホーム経由で取引登録画面まで遷移できるか確認する(個人、課金無し)' do
    @helpers.accounting.signup(plan: :trial)
    index = Pages::Accounting::Index.new
    index.header.navbar_menu.deal_link.hover
    index.header.navbar_menu.deal_dropdown_menu.deal_link.click
    deals_index = Pages::Accounting::Deals::Index.new
    deals_index.header.deals_tab_menu.deal_link.text).to eq '取引(収入・支出)'
    end

    View full-size slide

  51. 51
    ・2020/2 頃: URLとページファイルのディレクトリ構造とオブジェクト名の同一化
    ・改善内容
    ・テストシナリオの作成・読みやすさの向上
    /e2e-test
    ├─ lib テストシナリオで利用するクラス群
    │ ├─ helpers 複数のサービスで利用するサポートメソッドの置き場
    │ │ ├── accounting_helper 会計サービスのみで利用するサポートメソッドの置き場
    │ │ └── payroll_helper 人事労務サービスのみで利用するサポートメソッドの置き場
    │ ├─ pages ページオブジェクト置き場
    │ │ ├─ accounting 会計サービスのページオブジェクトの置き場
    │ │ │ ├── deals 会計サービスの/deals以下のページオブジェクトの置き場
    │ │ │ │ └── index.rb (例)会計サービスの/deals/indexのページオブジェクト
    │ │ │ └── index.rb (例)会計サービスの/indexのページオブジェクト
    │ │ ├─ payroll 人事労務サービスのページオブジェクトの置き場
    WEBのE2Eテストの運用と改善(9)
    ディレクトリ構造
    URLの" / " 区切りごとに
    ディレクトリ階層と一致させる

    View full-size slide

  52. 52
    ・2020/11頃から段階的に: 開発チームによるテストの運用
    ・運用内容
    ・テストスクリプト作成時、不安な方とのペア作業やコードレビュー
    ・初めて利用する人向けのドキュメントやコードスタイルガイドの提供
    ・機能改善や利用状況の社内PR
    ・改善内容
    ・SEQ担当者による要因分析待ちや、変更内容など情報共有の削減
    ・人員およびその構成:SEQ担当者だけでなく、開発チームの実施が徐々に拡大
    WEBのE2Eテストの運用と改善(10)

    View full-size slide

  53. 53
    ・2021/5 頃: レコード&リプレイ型の自動テストSaaSの併用開始
    ・運用内容
    ・実行失敗の要因分析
    ・改善内容
    ・プログラミングがさっとできなかったり、画面要素の変更が多い際でも
    E2Eテスト作成が容易になった
    ・人員およびその構成:一部のQA担当者
    WEBのE2Eテストの運用と改善(11)

    View full-size slide

  54. 54
    WEBのE2Eテストの運用と改善(11)
    ・2021/5 頃: レコード&リプレイ型の自動テストSaaSの併用開始
    ・既存のテストシステムとの使い分け
    ・サービスがプロトタイプを続けている状態の選択肢としている
    ・リリースも不定期で少なく、また変更も多いため、テストスクリプトを
    使い捨てするものと決めて利用する
    ・現時点ではまだ管理運用系の機能や実行単位でのコストなど足りない点が
    多いため、一部の利用としている

    View full-size slide

  55. 55
    ・2021/11 頃: Slackからの実行結果をスレッドに表示させる
    ・改善内容
    ・再実行時の結果把握容易化
    WEBのE2Eテストの運用と改善(12)

    View full-size slide

  56. 56
    WEBのE2Eテストの運用と改善(13)
    ・開発中: Pull Request上でE2Eテスト実行
    ・複数コンテナで構成されるサービスをPull Requestごとに起動させ、
    そこにE2Eテストを実行するシステム
    ・改善内容
    ・E2Eテスト失敗をリリースプロセス時ではなく、前倒しで発見する
    ・2022/11 現在: 約20サービス、370ファイル以上に対して、
    SEQ担当者による運用は、日々1名程度の運用係として
    おこなっている
    統合したWEBのE2Eテストリポジトリにお
    けるテストファイル数とサービス数

    View full-size slide

  57. 57
    1.freeeの自動テストの目的と使い方
    2.freeeの自動テストの「今」の構成
    3.自動テストの運用としておこなうこと
    4.freeeの自動テストの改善の歴史
    5.おわりに
    アジェンダ

    View full-size slide

  58. 58
    運用としておこなうこと
    ・自動テストの実行失敗時の要因分析
    ・自動テストの実行環境のアップデート
    ・自動テスト実行時間の適正化に向けたテストスクリプトや構成の変更
    ・自動テスト利用者の拡大のサポート
    ・運用の改善
    改善していること
    ・テスト実行を安定化させる
    ・テストスクリプトを作成しやすく、修正しやすくする
    ・運用の各作業の根本解消や容易化・自動化する
    自動テストの運用と改善としておこなうこと

    View full-size slide

  59. 59
    ・自動テストは、1つの開発チーム向けサービスと私は考えています。
    ・テスト対象の状態の変化や社内のメンバーの数やスキル、自動テストの量などに
    あわせて改善していくと、効果的であり、利用され続けます。
    ・数多くの課題は発生しますし期待もありますが、残念ながら1つの正解は
    存在しないので、考えながら改善していきましょう
    おわりに

    View full-size slide

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

    View full-size slide

  61. 61
    Meetyでサクッとお話し
    自動テストの実践に興味ある方、お話ししましょう!
    https://meety.net/matches/HtpcRgAiqvSo
    サービス間APIのテストやアクセシビリティテスト、パフォーマンステストなど、E2Eテスト以外の自動テスト基盤や
    効率的なテスト環境の整備など、やりたいことが山盛りです。
    今回の話を聞いて、freeeでの品質改善に興味持ってくれた方いませんか!?以下2つの窓口でお話ししませんか?
    興味がありましたら
    カジュアル面談
    ちょっと話を聞いてみたい位の人でもカジュアル面談で
    きます。気軽に応募ください!
    https://jobs.freee.co.jp/engineers/ ←の
    「募集職種一覧」>「QAエンジニアリング」>
    「SEQ(Software Engineer in Quality)」です。

    View full-size slide