Are your automated tests improving?

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

Transcript

1. 「皆さんの自動テストは改善されていますか？」 JaSST'22 Kyushu 2022.11.05 freee 株式会社
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
3. 3 これから自動テストをはじめる方へ ・自動テストの運用としておこなうことの一例を知れます すでに自動テストをおこなっている方へ ・自動テストを運用していくなかでの改善点やその解決策の一例を知れます ・自動テストを来週から改善していく際のヒントを得られます 今日の持ち帰り
4. 4 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
5. 5 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
6. 6 freeeは「スモールビジネスを、世界の主役に。」をミッションに掲げ、 統合型経営プラットフォームを開発・提供し、 だれもが自由に自然体で経営できる環境をつくっていきます。 起業やビジネスを育てていくことを、もっと魅力的で気軽な行為に。 個人事業や中小企業などのスモールビジネスに携わるすべての人が、 じぶんらしく自信をもって経営できるように。 大胆にスピード感をもってアイデアを具現化できるスモールビジネスは、 今までにない多様な価値観や生き方、 新しいイノベーションを生み出す起爆剤だと私たちは考えています。 スモールビジネスが大企業を刺激し、社会をさらにオモシロク、 世の中全体をより良くする流れを後押ししていきます。 Misson スモールビジネスを、世界の主役に。
7. 7 freee会計 freee開業 freee福利厚生 freeeアプリストア freee人事労務 freee会社設立 freeeスマート受発注 freeeプロジェクト管理 freee資金調達 freee申告 freeeカード プロダクトラインアップ
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月期
9. 9 freeeの自動テストの背景 ・多サービスかつ、今後も新規サービスは増えつつも、巨大なサービスがある状態も続く ・開発チームメンバーの異動や増加がそれなりに発生する ・高頻度のリリースのニーズが存在する
10. 10 freeeの自動テストの目的 継続的に開発しているため、リグレッションテストが欠かせない。 ただし、頻繁にお客様へ提供したい。 頻繁におこなわれるリリースに対して、リグレッションテストを極力短時間で実施する。 これは人力では困難であるため、自動実行されるリグレッションテストで実現する。 この自動実行されるリグレッションテストを、本講演では「自動テスト」と呼びます。
11. 11 freeeの開発における自動テストの基本的な使い方 基本的な使い方 ・開発中に、開発者による開発環境でのコマンド実行 ・各Pull Requestのコード更新時の自動実行 ・テスト環境デプロイ前後の自動実行 ・リリースワークフローでの自動実行 なお、テストスクリプトの作成や修正、運用は、プロダクトマネジャー、プログラマー、 テスト・QA担当者で構成される開発チームでおこなうものとしている
12. 12 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
13. 13 freeeの自動テスト ユニットテスト、APIテスト、ユースケースベースのEnd2Endテスト、様々な自動テストが社内では動いている freeeのサービスの提供形式としてはWEBとモバイルアプリがあり、それぞれの確認で自動テストを利用している 下記以外に、セキュリティやアクセシビリティのテストなどが半自動で実施されている 目指す自動テストと量 メソッド・モジュール・クラ ス・コンポーネントが設計通り の挙動・DOMとなるか APIレスポンスやレポート計算な ど複数モジュールやクラスの動 作が設計通りの挙動となるか 表示が想定通りか ユースケースが実施できるか 責務 言語が持つテスト フレームワークでのテスト snapshotテスト APIベースのユースケーステスト 数値計算系のテスト apiのテスト 表示の差分のテスト jestのテスト E2Eテスト ユニットテスト E2Eテスト 今回の講演での呼び名 APIテスト
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
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
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の 実績から推定
17. 17 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
18. 18 自動テストを提供するチームとして、以下のことをおこなっている ・自動テストの実行失敗時の要因分析 ・自動テストの実行環境のアップデート ・自動テスト実行時間の適正化に向けたテストスクリプトや構成の変更 ・自動テスト利用者の拡大のサポート ・運用の改善 自動テストの運用としておこなっていること
19. 19 自動テストの運用：自動テストの実行失敗時の要因分析 自動テストの実行失敗時の要因 ・テスト対象に不具合がある ・自動テストスクリプトがテスト対象の変更に追従できていない ・実行の不安定性 そこで、具体的におこなっていることとしては以下の4つ ・失敗箇所の特定 ・原因の推測 ・自動テストの再実行 ・失敗箇所に関する変更の確認
20. 20 自動テストの運用：自動テストの実行環境のアップデート ・テストフレームワークにおける利用ライブラリのアップデート ・自動テストの実行環境のOSのアップデートやセキュリティ対応 ・利用ブラウザのアップデート ・アップデートによりテストに影響がないか検証、および影響発生時の対応
21. 21 自動テストが増えた場合、そのままでは実行時間が長くなる。 頻繁に実行できるように、自動テスト実行時間を一定の時間内におさめる。 そこで、具体的におこなっていることとしては以下の3つ ・時間のかかっているテストや処理の特定 ・並列実行の構成変更 ・自動テストスクリプトや自動テストシステムの 不要な処理の削除や統合 自動テストの運用：自動テスト実行時間の適正化 週次のテストの平均・最大実行時間
22. 22 情報伝達の無駄の削減や自動テストの効果を最大化するために、 自動テストはできる限り多くの人に利用して貰いたい。 自動テストの利用者が社内で増えるよう、自動テストの利用サポートをおこなっている。 具体的におこなっていることとしては以下の3つ ・テストスクリプト作成時、不安な方とのペア作業やコードレビュー ・初めて利用する人向けのドキュメントやコードスタイルガイドの提供 ・機能改善や利用状況の社内PR 自動テストの運用：自動テスト利用者の拡大のサポート
23. 23 利用者が利用を開始するようになるまで 1．自動テストの効果を開発チームが理解するまで、価値を示し続ける ・自動テストで不具合が検知され、その不具合のインパクトが大きければ、 そしてそれが度々発生すれば、自動テストの価値は理解される 2．開発チームによる自動テストの利用・作成・修正する手間を1．の価値より低くする ・テストフレームワークの選択や様々な改善により手間を低くする 利用者が利用を継続していく ・必要なら継続する。使われなくなったら削除する ・メンテナンスされなくなったり、修正できないようであれば、そのテストの要不要の話し合いを おこない、必要であればチームにスキルをつけて貰うようにサポートし、不要なら削除する 上記に共通して、開始・継続する機会を逃さず提案・協働する （運用の話から脱線）自動テスト利用拡大に向けた考え方
24. 24 自動テストの運用：運用の改善 ・テスト実行を安定化させる ・テストへの信頼向上と、再実行の無駄を削除する ・テストスクリプトを作成しやすく、修正しやすくする ・利用者を拡大しやすくし、要因分析およびその後の修正を時間を短くする ・運用の各作業を容易化・自動化する ・無駄な作業を削除する
25. 25 E2Eテストでは、現在は経験的に全体のテスト成功率が93−94％を下回ってきたら、 また、個々のテスト成功率が5−10ポイント程度下がってきたら確認するようにしている 自動テストの運用の改善：テスト実行の安定化 ある1週間内でのE2Eテスト失敗率ベスト20の上位 週次のテスト実行数と成功率
26. 26 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
27. 27 自動テストの改善で意識していること ・利用者が増え、利用されることを第一の目標とする ・そのために、安定化・高速化・低い学習コストの仕掛けの構築、などをおこなう ・利用の当事者であり続ける ・運用の改善は無駄の削除だけでなく、利用者の精神的な苦痛の排除も視野に入れる ・シンプルな状態を保つ ・長く使う道具であり、突発的なことへの対応も期待されるので、シンプルな状態を保 つ
28. 28 1．利用者が自動テストを信頼して、利用できる基本を整える ・安定して利用できる ・待てる程度の実行時間で自動テストが終わる 2．持続的に運用できる状態を維持する ・運用の手間がかかる部分を解消する 3．利用者が自動テストを利用・作成・修正するための障壁を取り除く ・作成・修正しやすい環境を提供する ・利用しやすくする ・情報の拡充 自動テストの改善の優先順位：基本的な考え方
29. 29 短期的な改善の視点と長期的な改善の視点の両方を持って改善に取り組んでいる 短期的な視点で考えること：現テストシステムにおける各種改善 ・基本的な考え方で記載の順 ・なお、運用の手間がかかる部分の解消は、基本的に運用担当者のアイデアを生かす ・ペインを一番体感しているから 長期的な視点で考えること：テストシステムの刷新・追加 1．より利用者にとって使いやすいテストシステム 2．テスト実行時間の大きな改善 3．根本的な運用しにくさの解消 （別軸）手動では現実的にはできないが、確認できると効果があるテストの自動化 自動テストの改善の優先順位：短期・長期での考え方
30. 30 ・2012/7 (開発初期) 頃: RSpecのみ ・2014/10 頃: Jenkins 第1世代 ・2017/10 頃: Jenkins 第2世代（Jenkinsfile化） ・2017/12 頃: CircleCI(多並列化) ユニットテストの運用と改善の概要 いくつかのサービスのユニットテストおよび APIテストのファイル数
31. 31 ・2012/7 (開発初期) 頃: RSpecのみ ・開発環境での実施、1環境内ので並列実行 ・運用内容 ・実行失敗の要因分析 ・ライブラリのアップデート ・ときどき改善 ユニットテストの運用と改善(1)
32. 32 ユニットテストの運用と改善(2) ・2014/10 頃: Jenkins 第1世代 ・運用内容 ・実行失敗の要因分析 ・実行環境のアップデート ・実行時間の適正化 ・改善内容 ・並列実行による自動テスト実行の高速化 ・自分のPC以外でのテスト実行が可能になった ・実行環境と実行方法の追加： ・各Pull Requestのコード更新時の手動実行 ・Jenkinsからテスト環境デプロイ前やリリースプロセスで手動実施
33. 33 ユニットテストの運用と改善(3) ・2017/10 頃: Jenkins 第2世代 ・改善内容 ・実行環境の運用の改善：設定のファイル化 ・2017/12 頃: CircleCI ・改善内容 ・実行方法の追加： ・各Pull Requestのコード更新時の手動実行 ・実行環境の運用の改善：実行環境のIaC化 ・実行時間の適正化：多コンテナ実行
34. 34 ・運用内容 ・実行失敗時の要因分析 ・ライブラリのアップデート ・ときどき改善 ・改善内容 ・基本的には実行時間の適正化 ・無駄な前処理の削除 ・並列実行の改善 ・同一コンテナ内でのマルチプロセス実行 ・実行の動的変更、動きの遅い実行環境での実行を回避する：Knapsackの導入 ・確認の効率化 ・テスト実行を安定化させる ユニットテストの運用と改善(4)：その他
35. 35 ・2012/7 (開発初期) 頃: Request spec ・2019/9 頃: 会計帳簿計算用テストシステム稼働 ・2020/5 頃: Postman ・2020/11 頃: NewmanとJenkins での自動実行 APIテストの運用と改善の概要
36. 36 ・2012/7 (開発初期) 頃: Request spec ・以降、ユニットテストフレームワークを利用したAPIテストは、 ユニットテスト同様の運用と改善が適用される APIテストの運用と改善(1)
37. 37 ・2019/9 頃: 会計帳簿計算用テストシステム稼働 ・会計帳簿計算での不具合が発生したものの、手動では確認箇所が多過ぎて 現実的には確認できないため、自動テストでの実現が求められた ・設定が書かれたスプレッドシートから、APIを呼び出すユニットテスト形式の テストコードを生成し、リリースプロセスで実行する ・運用内容 ・ユニットテスト同様の運用 ・改善内容 ・新たなテストができるように専用自動テストシステムを開発 ・複数の開発者とSEQ担当者による作成・運用 APIテストの運用と改善(2)
38. 38 ・2020/5 頃: Postman ・手元PCからテスト環境デプロイ後に手動実施 ・運用内容 ・実行失敗の要因分析 ・改善内容 ・APIのシナリオテストができるようにツールを導入 ・1名のQA担当者による作成・運用 APIテストの運用と改善(3)
39. 39 APIテストの運用と改善(4) ・2020/11 頃: NewmanとJenkins での自動実行 ・運用内容 ・実行失敗の要因分析 ・実行環境のアップデート ・実行時間の適正化 ・改善内容 ・並列実行による自動テスト実行の高速化 ・自分のPC以外でのテスト実行が可能になった ・実行環境と実行方法の追加： ・Jenkinsからテスト環境デプロイ後やリリースプロセスで手動実施 ・特定のQA担当者以外でもSlackからの実行可能に ・複数のQA担当者とSEQ担当者による作成・運用
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テストリポジトリにお けるテストファイル数とサービス数
41. 41 ・2014/9 頃: Selenium IDE(レコード&リプレイ型のツール)によるテストシステム ・手元PCからテスト環境デプロイ後に手動実施 ・運用内容 ・実行失敗の要因分析 ・自動テストシナリオや利用サービス数：1サービスのみで導入。徐々にシナリオ増加 ・1名のQA担当者による作成・運用 WEBのE2Eテストの運用と改善(1)
42. 42 ・2015/2 頃: RubyのWebDriverによるテストシステム ・コードベースのテストシステムを導入 ・運用内容 ・実行失敗の要因分析 ・ライブラリのアップデート ・改善内容 ・複数人数で作成やレビューできるようになった ・自動テストシナリオや利用サービス数： ・2サービスから徐々に増え、最終的には5サービスで実施。シナリオも徐々に増加 ・徐々にメンバー増加。3名程度のQA担当者が片手間で作成・運用するようになった WEBのE2Eテストの運用と改善(2)
43. 43 ・2016 頃: RubyのWebDriverのJenkins実行 ・運用内容 ・実行失敗の要因分析 ・自動テストの実行環境のアップデート ・自動テスト実行時間の適正化 ・改善内容 ・並列実行による自動テスト実行の高速化 ・自分のPC以外でのテスト実行が可能になった ・QA担当者以外でのテスト実行が可能になった ・実行環境と実行方法の追加： Jenkinsからテスト環境デプロイ後やリリースプロセスで手動実施 WEBのE2Eテストの運用と改善(3)
44. 44 ・2016/6 頃: chatbotの導入 ・改善内容 ・実行方法の追加：Slackからのテスト実行開始が可能になった ・全ての人によるテスト実行が容易になった ・再実行までの時間が短くなった ・2017/10から段階的に: Jenkinsでの連携実行 ・改善内容 ・実行方法の変更：テスト環境デプロイ後やリリースプロセスで自動実施 ・リリース前に実施忘れがなくなり、作業をなくすることができた WEBのE2Eテストの運用と改善(4)
45. 45 ・2017/11 頃: Capybara+SitePrismによるテストシステム ・Ruby開発者が慣れているテストフレームワークを導入 ・運用内容 ・実行失敗の要因分析 ・ライブラリのアップデート ・改善内容 ・開発者による作成・修正などができるようになった ・テストシナリオとページファイルの分離により、テストの作成・修正が容易化 ・自動テストシナリオや利用サービス数： ・1つのサービスから導入開始し、最終的に2サービスで導入。シナリオは徐々に増加 ・RubyのWebDriverのテストシステムで動作していたサービスはそのまま ・数名の開発者とQA担当者が作成・運用するようになった WEBのE2Eテストの運用と改善(5)
46. 46 WEBのE2Eテストの改善の背景(2019〜) E2Eテストに関しては2019年後半くらいから、テストの実行回数 が増え、運用の作業量が増大したため、運用コストを大きく下げ る改善と開発チームを巻き込むための運用改善を重視した。 ・大きな運用コストを生んでいた課題： ・複数のE2Eテストシステムと複数リポジトリの運用 ・開発チームにとっての障壁： ・利用方法や作成に関する情報が不足していた ・低い成功率のため要因分析が高頻度で発生していた
47. 47 ・2019/9 頃: 結果の独自Slack通知 ・改善内容 ・実行失敗時の要因分析の高速化： ・失敗した際のテストのスタックトレースやスクリーンショットが 2クリックで見られるようになった WEBのE2Eテストの運用と改善(6)
48. 48 ・2019/10 頃: E2Eテストの実行結果のデータ基盤への格納・可視化 ・2016/9頃から2017/11頃も格納されていたが利用されず停止していた ・改善内容 ・不安定なE2Eテストやサービスを、実行状況を週次や月次などの視点から 把握、改善できるようになった WEBのE2Eテストの運用と改善(7) 週次のテスト実行数と成功率 週次のテストの平均・最大実行時間
49. 49 ・2019/12頃から段階的に: Capybara+SitePrismの全サービス共通構成 によるテストシナリオ（現行の基本システム） ・運用内容 ・実行失敗の要因分析 ・ライブラリ・実行環境のアップデート ・実行時間の適正化 ・改善内容 ・全サービスで、同一の使い方や、テスト作成・修正が可能になった ・運用すべき箇所が1つに統合されたため、運用コストを下げられ、 改善も一括提供できるようになった。 ・人員およびその構成：1名のSEQ担当者と3名のアルバイトで運用開始 WEBのE2Eテストの運用と改善(8)
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
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の" / " 区切りごとに ディレクトリ階層と一致させる
52. 52 ・2020/11頃から段階的に: 開発チームによるテストの運用 ・運用内容 ・テストスクリプト作成時、不安な方とのペア作業やコードレビュー ・初めて利用する人向けのドキュメントやコードスタイルガイドの提供 ・機能改善や利用状況の社内PR ・改善内容 ・SEQ担当者による要因分析待ちや、変更内容など情報共有の削減 ・人員およびその構成：SEQ担当者だけでなく、開発チームの実施が徐々に拡大 WEBのE2Eテストの運用と改善(10)
53. 53 ・2021/5 頃: レコード＆リプレイ型の自動テストSaaSの併用開始 ・運用内容 ・実行失敗の要因分析 ・改善内容 ・プログラミングがさっとできなかったり、画面要素の変更が多い際でも E2Eテスト作成が容易になった ・人員およびその構成：一部のQA担当者 WEBのE2Eテストの運用と改善(11)
54. 54 WEBのE2Eテストの運用と改善(11) ・2021/5 頃: レコード＆リプレイ型の自動テストSaaSの併用開始 ・既存のテストシステムとの使い分け ・サービスがプロトタイプを続けている状態の選択肢としている ・リリースも不定期で少なく、また変更も多いため、テストスクリプトを 使い捨てするものと決めて利用する ・現時点ではまだ管理運用系の機能や実行単位でのコストなど足りない点が 多いため、一部の利用としている
55. 55 ・2021/11 頃: Slackからの実行結果をスレッドに表示させる ・改善内容 ・再実行時の結果把握容易化 WEBのE2Eテストの運用と改善(12)
56. 56 WEBのE2Eテストの運用と改善(13) ・開発中: Pull Request上でE2Eテスト実行 ・複数コンテナで構成されるサービスをPull Requestごとに起動させ、 そこにE2Eテストを実行するシステム ・改善内容 ・E2Eテスト失敗をリリースプロセス時ではなく、前倒しで発見する ・2022/11 現在: 約20サービス、370ファイル以上に対して、 SEQ担当者による運用は、日々1名程度の運用係として おこなっている 統合したWEBのE2Eテストリポジトリにお けるテストファイル数とサービス数
57. 57 1.freeeの自動テストの目的と使い方 2.freeeの自動テストの「今」の構成 3.自動テストの運用としておこなうこと 4.freeeの自動テストの改善の歴史 5.おわりに アジェンダ
58. 58 運用としておこなうこと ・自動テストの実行失敗時の要因分析 ・自動テストの実行環境のアップデート ・自動テスト実行時間の適正化に向けたテストスクリプトや構成の変更 ・自動テスト利用者の拡大のサポート ・運用の改善 改善していること ・テスト実行を安定化させる ・テストスクリプトを作成しやすく、修正しやすくする ・運用の各作業の根本解消や容易化・自動化する 自動テストの運用と改善としておこなうこと
59. 59 ・自動テストは、1つの開発チーム向けサービスと私は考えています。 ・テスト対象の状態の変化や社内のメンバーの数やスキル、自動テストの量などに あわせて改善していくと、効果的であり、利用され続けます。 ・数多くの課題は発生しますし期待もありますが、残念ながら1つの正解は 存在しないので、考えながら改善していきましょう おわりに
60. スモールビジネスを、世界の主役に。
61. 61 Meetyでサクッとお話し 自動テストの実践に興味ある方、お話ししましょう！ https://meety.net/matches/HtpcRgAiqvSo サービス間APIのテストやアクセシビリティテスト、パフォーマンステストなど、E2Eテスト以外の自動テスト基盤や 効率的なテスト環境の整備など、やりたいことが山盛りです。 今回の話を聞いて、freeeでの品質改善に興味持ってくれた方いませんか！？以下2つの窓口でお話ししませんか？ 興味がありましたら カジュアル面談 ちょっと話を聞いてみたい位の人でもカジュアル面談で きます。気軽に応募ください！ https://jobs.freee.co.jp/engineers/ ←の 「募集職種一覧」>「QAエンジニアリング」> 「SEQ（Software Engineer in Quality）」です。