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

モバイルアプリにおける自動テストの導入戦略

Takuma Osada
December 06, 2024

 モバイルアプリにおける自動テストの導入戦略

私の所属するチームでは、品質維持を目指してテスト戦略の見直しを行い、その結果、integration_testを用いた自動テストの導入に至りました。
これまで2年間の運用を通じて、現在では自動テストのシナリオ数は70を超えています。導入に至った意思決定や運用時の課題とその解決方法についてお話しします。

Takuma Osada

December 06, 2024
Tweet

More Decks by Takuma Osada

Other Decks in Programming

Transcript

  1. STAR Software Testing Automation Research 2 自 己 紹介 長田

    卓 馬 株式会社サイバーエージェント 21年度新卒 入 社 Flutter Engineer マイブームはバズレシピ系 YouTuber の動画 見 ながらの料理 • GitHub ID: ostk 0 0 6 9 • X ID: ostk 0 0 6 9
  2. STAR Software Testing Automation Research 5 本 日 のゴール WINTICKET

    での 自 動テストの導 入 プロセスを理解し いつでもプロダクトに 自 動テストの導 入 できる状態に 💪
  3. STAR Software Testing Automation Research 6 AGENDA 1. モバイルアプリのテスト戦略の 見

    直しと 自 動テスト導 入 決定まで 2. 自 動テストの導 入 期について 3. 自 動テストのシナリオ拡張期 ・ 運 用 期について 4. 自 動テストを安定するまで運 用 してみて
  4. STAR Software Testing Automation Research 7 1. モバイルアプリのテスト戦略の 見 直しと

    自 動テスト導 入 決定まで 1. テスト戦略 見 直しの背景 2. 既存のテスト体制を把握する 3. 過去のインシデントから改善点を把握する
  5. STAR Software Testing Automation Research 9 1.1. テスト戦略 見 直しの背景

    テスト戦略を考える上で、プロダクトの性質や、 チームの体制、QA / QC の状態を理解することが 非 常に 大 切 ⚠
  6. STAR Software Testing Automation Research 1 0 1.1. テスト戦略 見

    直しの背景 👨💻 👨💻 👨💻 👨💻 👨💻 👨💻 👨💻 機能開発チーム Platformチーム アプリチーム 機能開発をメインに担当 CI/CDや基盤など 機能開発以外を担当
  7. STAR Software Testing Automation Research 1 1 1.1. テスト戦略 見

    直しの背景 👨💻 👨💻 👨💻 👨💻 👨💻 👨💻 👨💻 機能開発チーム SREチーム アプリチーム 機能開発をメインに担当 CI/CDや基盤など機能開発以外を担当 Platform チームの 2023 年以降のミッション 「アプリの可 用 性を向上させる」 👨💻 👨💻 👨💻
  8. STAR Software Testing Automation Research 1 2 1.1. テスト戦略 見

    直しの背景 可 用 性とは... 可 用 性 (%) = 稼働時間 / (停 止 時間 + 稼働時間) 停 止 時間 (h) = 平均修復時間* x 3 6 5 日 x 2 4 時間 / 平均故障間隔* 平均修復時間 = 停 止 時間の合計 / 失敗の回数 平均故障間隔 = 稼働時間の合計 / 失敗の回数
  9. STAR Software Testing Automation Research 1 3 1.1. テスト戦略 見

    直しの背景 2022 年の状況 • 変更障害率: 7.5 % (3/40) • 平均停 止 時間: 4.0 日 • 可 用 性: 96.8 %
  10. STAR Software Testing Automation Research 1 4 1.1. テスト戦略 見

    直しの背景 2022 年の状況 • 変更障害率: 7.5 % (3/40) • 平均停 止 時間: 4.0 日 • 可 用 性: 96.8 % 2023 年以降の 目 標 • 変更障害率: 5 % • 平均停 止 時間: 3.0 日 • 可 用 性: 98.4 % →
  11. STAR Software Testing Automation Research 1 5 1.1. テスト戦略 見

    直しの背景 目 標を達成するために
  12. STAR Software Testing Automation Research 目 標を達成するために 1 6 1.1.

    テスト戦略 見 直しの背景 📈 平均障害率を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する
  13. STAR Software Testing Automation Research 目 標を達成するために 1 7 1.1.

    テスト戦略 見 直しの背景 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する
  14. STAR Software Testing Automation Research 目 標を達成するために 1 8 1.1.

    テスト戦略 見 直しの背景 本セッションではこちらはスキップ 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する
  15. STAR Software Testing Automation Research 目 標を達成するために 1 9 1.1.

    テスト戦略 見 直しの背景 本セッションではこちらはスキップ 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する FlutterKaigi 2 0 2 4 での登壇が YouTubeにアップロードされています https://www.youtube.com/watch?v=CE 0 NTGJLbS 8 &t= 3 0 2 4 5 s
  16. STAR Software Testing Automation Research 目 標を達成するために 2 0 1.1.

    テスト戦略 見 直しの背景 本セッションではこちらはスキップ 📈 平均障害率を下げる 🕐 平均修復時間を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の 見 直しを実施する • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の 見 直しを実施する WINTICKETのアプリチームの技術戦略やこれまでに興味がある 方 は ぜひこちらも視聴いただけると嬉しいです https://www.youtube.com/watch?v=mzxKTsNmSBc&ab_channel=CyberAgentDevelopers
  17. STAR Software Testing Automation Research 2 1 1.2. 既存のテスト体制を把握する テストピラミッドについて

    End to End Test Integration Test Unit Test Manual Test Manual Test: 手 動で機能が正常に動くか End to End Test: シナリオを形成し、機能単位で アプリケーションが期待通りに実 行 されるか Integration Test: 複数のユニットが期待通りに実 行 されるか Unit Test: 単 一 クラスや関数が期待通りに実 行 されるか
  18. STAR Software Testing Automation Research 2 2 1.2. 既存のテスト体制を把握する WINTICKET

    の 自 動テスト導 入 前のテスト体制 End to End Test Integration Test Unit Test Manual Test Manual Test: QC、リリース前にアプリチームでの検証 End to End Test: 試験的に導 入 したシナリオがひとつ Integration Test: なし Unit Test: レイヤーによってカバレッジが 高 い箇所と 低い箇所が存在する
  19. STAR Software Testing Automation Research 2 3 1.2. 既存のテスト体制を把握する 🤔

    Unit Test の拡充を進めるか… E 2 E Test の拡充を進めるか… 全く新しい道を模索するか… (そんなものはあるのか…?)
  20. STAR Software Testing Automation Research 2 4 1.2. 既存のテスト体制を把握する 🤔

    Unit Test の拡充を進めるか… E 2 E Test の拡充を進めるか… 全く新しい道を模索するか… (そんなものはあるのか…?) 過去の障害事例から注 力 ポイントを 見 つける 👀
  21. STAR Software Testing Automation Research 過去に障害が起きた Pull Request を分別する( 大小

    問わず 9 件からまとめたもの) 2 5 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に 見 つけられなかった 不具合や仕様の考慮漏れ Renovate や Dependabot による Package の依存更新時の不具合 既存のコードの改修から発 生 する不具合 既存からある機能の不具合の改修に伴う 副作 用 から発 生 する不具合 Feature Flag の利 用 発 生 件数 テスターによる QC の有無
  22. STAR Software Testing Automation Research 2 6 1.3. 過去のインシデントから改善点を把握する 過去に障害が起きた

    Pull Request を分別する( 大小 問わず 9 件からまとめたもの) 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に 見 つけられなかった 不具合や仕様の考慮漏れ Renovate や Dependabot による Package の依存更新時の不具合 既存のコードの改修から発 生 する不具合 既存からある機能の不具合の改修に伴う 副作 用 から発 生 する不具合 Feature Flag の利 用 発 生 件数 テスターによる QC の有無 ✅ ❌ ❌ ❌
  23. STAR Software Testing Automation Research 2 7 1.3. 過去のインシデントから改善点を把握する 過去に障害が起きた

    Pull Request を分別する( 大小 問わず 9 件からまとめたもの) 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に 見 つけられなかった 不具合や仕様の考慮漏れ Renovate や Dependabot による Package の依存更新時の不具合 既存のコードの改修から発 生 する不具合 既存からある機能の不具合の改修に伴う 副作 用 から発 生 する不具合 Feature Flag の利 用 発 生 件数 テスターによる QC の有無 ✅ ❌ ❌ ❌ ✅ ✅ ❌ ❌
  24. STAR Software Testing Automation Research 2 8 1.3. 過去のインシデントから改善点を把握する 過去に障害が起きた

    Pull Request を分別する( 大小 問わず 9 件からまとめたもの) 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に 見 つけられなかった 不具合や仕様の考慮漏れ Renovate や Dependabot による Package の依存更新時の不具合 既存のコードの改修から発 生 する不具合 既存からある機能の不具合の改修に伴う 副作 用 から発 生 する不具合 Feature Flag の利 用 発 生 件数 2 件 5 件 1 件 テスターによる QC の有無 ✅ ❌ ❌ ❌ ✅ ✅ ❌ ❌ 1 件
  25. STAR Software Testing Automation Research 過去に障害が起きた Pull Request を分別する( 大小

    問わず 9 件からまとめたもの) 2 9 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に 見 つけられなかった 不具合や仕様の考慮漏れ 既存のコードの改修から発 生 する不具合 既存からある機能の不具合の改修に伴う 副作 用 から発 生 する不具合 ✅ ❌ Feature Flag の利 用 発 生 件数 1 件 2 件 5 件 1 件 ❌ ❌ ✅ ✅ ❌ ❌ テスターによる QC の有無 QC を実施しておらず、注 力 ポイントになりそう👊 Renovate や Dependabot による Package の依存更新時の不具合
  26. STAR Software Testing Automation Research 起きた障害に対するテストの種別ごとに導 入 した際の効果 3 0

    1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング 不具合修正 VRT - Unit Test Integration Test E 2 E Test - 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです 中 小 中 中 小 中 中 小 小 小 大 大 大 中
  27. STAR Software Testing Automation Research 🚧 2024 年 12 月

    時点の WINTICKET のアプリチーム独 自 の判断によるものです 起きた障害に対するテストの種別ごとに導 入 した際の効果 3 1 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング 不具合修正 VRT 大 - Unit Test Integration Test E 2 E Test 大 大 中 - 中 小 中 中 小 小 小 中 小 中 他のテスト 手 法よりも不具合防 止 の効果が 高 い📈
  28. STAR Software Testing Automation Research 現在(2022 年 8 月 )と注

    力 した場合の差分を挙げる 3 2 1.3. 過去のインシデントから改善点を把握する 現在の網羅率 追加コスト VRT Unit Test Integration Test E 2 E Test 5 0 % 追加時の効果 9 0 % ~ 0 % 5 % 小 ~ 中 小 中 ~ 大 中 ~ 大 大 小 小 小 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  29. STAR Software Testing Automation Research 🚧 2024 年 12 月

    時点の WINTICKET のアプリチーム独 自 の判断によるものです 現在(2022 年 8 月 )と注 力 した場合の差分を挙げる 3 3 1.3. 過去のインシデントから改善点を把握する 現在の網羅率 追加コスト VRT Unit Test Integration Test E 2 E Test 追加時の効果 5 0 % 9 0 % ~ 5 % 小 ~ 中 小 中 ~ 大 中 ~ 大 大 小 小 小 0 % 追加コストは 大 きいが、その分効果も期待できる💪
  30. STAR Software Testing Automation Research 3 4 1.3. 過去のインシデントから改善点を把握する まとめ

    次の理由から、E 2 Eテストの強化に注 力 する ✅ 他のテスト 手 法に 比 べ、問題が多く発 生 する箇所(依存の更新、リファクタリング、バグ修正)への対 策が期待できる ✅ 追加コストは 高 いが、まだ網羅していない機能が多く、導 入 後の効果が 大 いに期待できる
  31. STAR Software Testing Automation Research 3 5 2. 自 動テストの導

    入 期について 1. プロダクトに合うツール選定を 行 う 2. テスターによる 手 動テストとの差別化
  32. STAR Software Testing Automation Research 3 6 2.1. プロダクトに合うツール選定を 行

    う 自 動テストのツールの種類 • SaaS ツールを利 用 する Eg: Autify for Mobile、MagicPod … • OSS ツールを利 用 する Eg: Appium、Maestro … • Plaform が提供しているツールを利 用 する Eg: integration_test、XCTest、Espresso …
  33. STAR Software Testing Automation Research 3 7 2.1. プロダクトに合うツール選定を 行

    う 自 動テストのツールの種類 • SaaS ツールを利 用 する Eg: Autify for Mobile、MagicPod … • OSS ツールを利 用 する Eg: Appium、Maestro … • Plaform が提供しているツールを利 用 する Eg: integration_test、XCTest、Espresso …
  34. STAR Software Testing Automation Research 3 8 2.1. プロダクトに合うツール選定を 行

    う 自 動テストのツールの 比 較 - Autify for Mobile ノーコードを使ったソフトウェアテスト 自 動化プラットフォーム。 https://autify.com/ja/mobile 2023 年 2 月 に Android に正式対応。プラットフォーム依存しないため、 Flutter 以外の iOS、Android、React Native での実 行 も可能。 社内での利 用 実績あり、WINTICKET でも Web で利 用 中。 選定にあたり、実際にトライアルで検証を 行 った。
  35. STAR Software Testing Automation Research 3 9 2.1. プロダクトに合うツール選定を 行

    う 自 動テストのツールの 比 較 - Maestro シナリオ作成の 言 語として Yaml を採 用 したUIテストツール。 https://maestro.mobile.dev プラットフォーム依存しないため、Flutter 以外の iOS、 Android、React Native でも実 行 可能。 Yamlを採 用 することで、シンプルな記述でシナリオ作成が 可能となる。このツールは、"Maestro Cloud” と呼ばれる環境下で 実 行 可能。 ⚠ Maestro Cloud 上での実機での実 行 のサポートは現在なし
  36. STAR Software Testing Automation Research 4 0 2.1. プロダクトに合うツール選定を 行

    う 自 動テストのツールの 比 較 - integration_test Flutter 公式から提供されるテストツールで、iOS の XCTest や Android のEspresso と同等の位置づけ。 https://docs. fl utter.dev/testing/integration-tests 記述はDartのみ可能。 初回のパフォーマンス向上を 目 的としたSkSL 生 成に、 実 行 シナリオを利 用 可能。
  37. STAR Software Testing Automation Research 4 1 2.1. プロダクトに合うツール選定を 行

    う ツールに求める要件 🚧 開発環境の画像になります MUST • 頻繁に状態がかわる UI への対応 力 • 多種多様な環境での実 行 可能性 BETTER • エンジニアのシナリオ作成コストが低い • 運 用 にかかる費 用 が安い 💰
  38. STAR Software Testing Automation Research 4 2 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile Maestro integration_test 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  39. STAR Software Testing Automation Research 4 3 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile Maestro integration_test ❌ ✅ ✅ 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  40. STAR Software Testing Automation Research 4 4 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile Maestro integration_test ❌ ✅ ✅ ❌ ❌ ✅ 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  41. STAR Software Testing Automation Research 4 5 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile Maestro integration_test ❌ ✅ ✅ ❌ ❌ ✅ 🤔 ✅ ❌ 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  42. STAR Software Testing Automation Research 4 6 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile Maestro integration_test ❌ ✅ ✅ ❌ ❌ ✅ 🤔 ✅ ❌ ✅ ❌ ✅ 🚧 2024 年 12 月 時点の WINTICKET のアプリチーム独 自 の判断によるものです
  43. STAR Software Testing Automation Research 🚧 2024 年 12 月

    時点の WINTICKET のアプリチーム独 自 の判断によるものです 4 7 2.1. プロダクトに合うツール選定を 行 う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile ❌ Maestro integration_test ❌ 🤔 ✅ ❌ ✅ ❌ ✅ ❌ ✅ ✅ ✅ 作成コストは 大 きいが、他の条件を満たしている✅ 多種多様な環境での実 行 可能性
  44. STAR Software Testing Automation Research 4 8 2.1. プロダクトに合うツール選定を 行

    う WINTICKET がツールに求める要件 頻繁に状態がかわる UI への対応 力 多種多様な実 行 環境での実 行 可能性 エンジニアのシナリオ作成コストが低い 運 用 にかかる費 用 が安い Autify for Mobile ❌ Maestro integration_test - 🚧 2022 年 8 月 当時の WINTICKET のアプリチーム独 自 の判断によるものです ❌ 🤔 ✅ ❌ ✅ ❌ ✅ ❌ ✅ ✅ ✅ 作成コストは 大 きいが、他の条件を満たしている✅ integration_test を 自 動テストのツールとして採 用 😎
  45. STAR Software Testing Automation Research 4 9 2.2. テスターによる 手

    動テストとの差別化 🧑💻 「E 2 E Test は 手 動 QC の 自 動化をゴールにやるんですか?」
  46. STAR Software Testing Automation Research 5 0 2.2. テスターによる 手

    動テストとの差別化 🧑💻 「E 2 E Test は 手 動 QC の 自 動化をゴールにやるんですか?」 A.「やりません🙅」
  47. STAR Software Testing Automation Research 5 1 2.2. テスターによる 手

    動テストとの差別化 WINTICKET の QC 体制 変更差分のない コード 依存 Package の更新 新機能の コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし ❌ QC 実施なし
  48. STAR Software Testing Automation Research 5 2 2.2. テスターによる 手

    動テストとの差別化 WINTICKET の QC 体制 変更差分のない コード 依存 Package の更新 新機能の コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし Flutter のバージョン更新、 FlutterFire や、RiverPod などの 大 きな依存は全機能 QC を実施 ✅ ✅ QC 実施
  49. STAR Software Testing Automation Research 5 3 2.2. テスターによる 手

    動テストとの差別化 テスターによる 手 動テストとの差別化
  50. STAR Software Testing Automation Research 5 4 2.2. テスターによる 手

    動テストとの差別化 テスターによる 手 動テストとの差別化 変更差分のない コード 依存 Package の更新 新機能の コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし ❌ QC 実施なし
  51. STAR Software Testing Automation Research 5 5 2.2. テスターによる 手

    動テストとの差別化 テスターによる 手 動テストとの差別化 変更差分のない コード 依存 Package の更新 新機能の コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ✅ E 2 E Test でカバーする
  52. STAR Software Testing Automation Research 5 6 2.2. テスターによる 手

    動テストとの差別化 メリット • 新機能開発のリソースを 自 動テストのシナ リオ作成でひっ迫させない • 自 動テストによる精度の限界を 手 動テストでカバー
  53. STAR Software Testing Automation Research 5 7 2.2. テスターによる 手

    動テストとの差別化 メリット • 新機能開発のリソースを 自 動テストのシナ リオ作成でひっ迫させない • 自 動テストによる精度の限界を 手 動テストでカバー デメリット • シナリオ作成を忘れてしまう • 自 動テストでテスターさんの 検証コストをカバーできていない
  54. STAR Software Testing Automation Research 5 8 2.2. テスターによる 手

    動テストとの差別化 メリット • 新機能開発のリソースを 自 動テストのシナ リオ作成でひっ迫させない • 自 動テストによる精度の限界を 手 動テストでカバー デメリット • シナリオ作成を忘れてしまう • 自 動テストでテスターさんの 検証コストをカバーできていない フロー化することでカバー 自 動テストの精度がテスターさんによる 手 動検証の精度を上回るのは無理だと判断
  55. STAR Software Testing Automation Research 5 9 2.2. テスターによる 手

    動テストとの差別化 メリット • 自 動テストのシナリオ作成が 機能開発のリソースをひっ迫させない • 自 動テストによる精度の限界を 手 動テストでカバー デメリット • シナリオ作成を忘れてしまう • 自 動テストのシナリオでテスターさんの 検証コストをカバーできていない フロー化することでカバー 自 動テストの品質がテスターさんによる 手 動検証の品質を上回るのは無理だと判断 E 2 E Test は QC の 自 動化をせず、QC と並 走 して、 QC の範囲外の項 目 でのデグレ検知を 目 的として利 用 🤝
  56. STAR Software Testing Automation Research 6 0 3. 自 動テストの

    シナリオ拡張期 ・ 運 用 期について 1 . Test Matrix から注 力 ポイントを分析する 2 . Robot Pattern の採 用 とコーディングルールの制定 3 . OS の UI 箇所を触れるようにする 4. 機能別のシナリオ作成のやる ・ やらないの 判断基準、優先度を標準化 5. 不安定なシナリオへの対応策 6 . Hot Restart でのシナリオの実装を可能にする 7. 運 用 時のシナリオの実 行 頻度やその 方 法 8. 随時追加される機能のシナリオを どのように担保するか
  57. STAR Software Testing Automation Research Test Matrix とは ... E

    ff ort (テストに必要な労 力 ) と Con fi dence (テスト実 行 による信頼性) を図 示 したものです。 6 1 3 . 1 . Test Matrix から注 力 ポイントを分析する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid
  58. STAR Software Testing Automation Research Test Matrix とは ... E

    ff ort (テストに必要な労 力 ) と Con fi dence (テスト実 行 による信頼性) を図 示 したものです。 6 2 3 . 1 . Test Matrix から注 力 ポイントを分析する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence
  59. STAR Software Testing Automation Research 6 3 3 . 1

    . Test Matrix から注 力 ポイントを分析する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid E ff ort • インストール: テストが実 行 できる環境の準備 • 作成: テスト作成の難易度や所要時間 • 実 行 : テスト スイートの実 行 にかかる時間 • デバッグ: 失敗時に問題の特定と修正のしやすさ • メンテナンス: 維持するために必要なコスト
  60. STAR Software Testing Automation Research 6 4 3 . 1

    . Test Matrix から注 力 ポイントを分析する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid E ff ort Con fi dence • インストール: テストが実 行 できる環境の準備 • 作成: テスト作成の難易度や所要時間 • 実 行 : テスト スイートの実 行 にかかる時間 • デバッグ: 失敗時に問題の特定と修正のしやすさ • メンテナンス: 維持するために必要なコスト テストがもたらすアプリケーションの信頼性
  61. STAR Software Testing Automation Research 6 5 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の E ff ort とは ... • インストール: テストが実 行 できる環境の作成時間 • 作成: テスト作成の難易度や所要時間 • 実 行 : テスト スイートの実 行 にかかる時間 • デバッグ: テスト失敗時に問題の特定と修正のしやすさ • メンテナンス: テストを維持するために必要なコスト https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence Unit Test
  62. STAR Software Testing Automation Research 6 6 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の E ff ort とは ... • インストール: テストが実 行 できる環境の作成時間 • 作成: テスト作成の難易度や所要時間 • 実 行 : テスト スイートの実 行 にかかる時間 • デバッグ: テスト失敗時に問題の特定と修正のしやすさ • メンテナンス: テストを維持するために必要なコスト https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence プロジェクトの成熟に伴い、 機能追加だけだと少しずつ E ff ort が増加していく Unit Test
  63. STAR Software Testing Automation Research 6 7 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する 全ての機能のシナリオを導 入 したと仮定した際のE 2 E Testをそれぞれを図内に プロットし、E 2 E Test の課題点を把握する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid
  64. STAR Software Testing Automation Research 6 8 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する Unit Test、VRT Test、E 2 E Test それぞれを図内に プロットし、E 2 E Test の課題点を把握する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence Unit Test VRT Test
  65. STAR Software Testing Automation Research 6 9 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する Unit Test、VRT Test、E 2 E Test それぞれを図内に プロットし、E 2 E Test の課題点を把握する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence Unit Test VRT Test E 2 E Test E 2 E Test そもそも書けない ・ 書くのが難しいシナリオ →
  66. STAR Software Testing Automation Research 7 0 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する Unit Test、VRT Test、E 2 E Test それぞれを図内に プロットし、E 2 E Test の課題点を把握する https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid Low E ff ort High E ff ort High Con fi dence Low Con fi dence E 2 E Test E 2 E Test そもそも書けない ・ 書くのが難しいシナリオ → E 2 E Test High E ff ort になってる原因 を改善し、E 2 E をLow E ff ort へ Unit Test VRT Test
  67. STAR Software Testing Automation Research 7 1 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する E 2 E Test の状況 • ✅ インストール: 特になし • ❌ 作成: 実装コストが 大 きいシナリオ、作成が難しいシナリオが存在する • ❌ 実 行 : 実 行 が不安定なシナリオが存在する • ❌ デバッグ: Hot Restart が使 用 できないため、問題の検出に 手 間がかかる • 🤔 メンテナンス: 機能追加/修正に伴うシナリオ修正が必要 https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid
  68. STAR Software Testing Automation Research 7 2 3 . 1

    . Test Matrix から注 力 ポイントを分析する Test Matrix の考え 方 を応 用 する E 2 E Test の状況 • ✅ インストール: 特になし • ❌ 作成: 実装コストが 大 きいシナリオ、作成が難しいシナリオが存在する • ❌ 実 行 : 実 行 が不安定なシナリオが存在する • ❌ デバッグ: Hot Restart が使 用 できないため、問題の検出に 手 間がかかる • 🤔 メンテナンス: 機能追加/修正に伴うシナリオ修正が必要 https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead https://semaphoreci.com/blog/testing-pyramid 特に改善に繋がりそうな 「作成」「実 行 」「デバッグ」 への改善策を考える
  69. STAR Software Testing Automation Research 7 3 3 . 1

    . Test Matrix から注 力 ポイントを分析する 「作成」の E ff ort の課題 • 実装コストが 大 きいシナリオが存在する → 3.2. ロボットパターンの採 用 とコーディングルールの制定 • 作成が難しいシナリオが存在する → 3 . 3 . OS のUI 箇所を触れるようにする • シナリオを書いても High Con fi dence に繋がらないシナリオが存在する → 3.5. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化
  70. STAR Software Testing Automation Research 7 4 3 . 1

    . Test Matrix から注 力 ポイントを分析する • 実 行 が不安定なシナリオが存在する → 3.6. 不安定なシナリオへの対応策 • Hot Restart が使 用 できないため、問題の検出に 手 間がかかる → 3 . 7 . Hot Restart でのシナリオの実装を可能にする 「実 行 」の E ff ort の課題 「デバッグ」の E ff ort の課題
  71. STAR Software Testing Automation Research 7 5 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 E 2 E Test のデザインパターン - Robot Pattern 🤖 テスト対象のセグメンテーション(eg. 画 面 )ごとに Robot Object を 用 意し、テストコード上にテストの What(テストしたい振る舞いや仕様)を、Robot Object にテストの How(Tap や Enter Textなどのアク ションや期待値 比 較の実装)を実装する https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/
  72. STAR Software Testing Automation Research 7 6 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 E 2 E Test のデザインパターン - Robot Pattern テスト対象のセグメンテーション(eg. 画 面 )ごとに Robot Object を 用 意し、テストコード上にテストの What(テストしたい振る舞いや仕様)を、Robot Object にテストの How(Tap や Enter Textなどのアク ションや期待値 比 較の実装)を実装する https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/ integration_test のみの実装と Robot Pattern を利 用 した実装を 比 較していく 👀
  73. STAR Software Testing Automation Research 7 7 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - integration_test の標準的な実装 https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/
  74. STAR Software Testing Automation Research 7 8 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - integration_test の標準的な実装 https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/ アプリの起動 Username と Passwordの 入力 + ログインボタンのタップ “Success” の 文 字が 見 えるか照合
  75. STAR Software Testing Automation Research 7 9 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - Robot Pattern を利 用 した Robot Class のサンプル https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/
  76. STAR Software Testing Automation Research 8 0 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - Robot Pattern を利 用 した Robot Class のサンプル https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/ Robot Class の定義 Tester Class を Wrap する形で それぞれのアクション関数を作成
  77. STAR Software Testing Automation Research 8 1 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - Robot Pattern を利 用 した Robot Class のサンプル https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/ 画 面 ごとの Robot Class を宣 言 し、 その後アクション関数を呼び出す
  78. STAR Software Testing Automation Research 8 2 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Pattern のサンプル - Robot Pattern を利 用 した Robot Class のサンプル https://goyoki.hatenablog.com/entry/ 2 0 2 1 / 0 4 / 2 2 / 0 0 3 6 5 8 https://jakewharton.com/testing-robots/ コード量 自 体はあまり変化はないが、 可読性が上がっているのがわかる 👀
  79. STAR Software Testing Automation Research 8 3 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 E 2 E Testのデザインパターン - Robot Pattern 最終的に Robot Pattern の考えをベースに以下の形で落ち着いた • Robot Class を PageDriver Class と PageFindable Class に分割 • 認証やオンボーディング画 面 などの 一 連の動作の流れを共通化するための FlowDriver Class を作成
  80. STAR Software Testing Automation Research 8 4 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 Robot Class を PageDriver Class と PageFindable Class に分割
  81. STAR Software Testing Automation Research 8 5 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 E 2 E Testのデザインパターン - Robot Pattern 最終的に Robot Pattern の考えをベースに以下の形で落ち着いた • Robot Class を PageDriver Class と PageFindable Class に分割 • 認証やオンボーディング画 面 などの 一 連の動作の流れを共通化するための FlowDriver Class を作成 Robot Class 同様、アクション関数を定義し、 呼び出すための Class Driver Class が利 用 するコンポーネントの 定義を集約し、管理するための Class
  82. STAR Software Testing Automation Research 8 6 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 一 連の動作の流れを共通化するための FlowDriver Class の作成
  83. STAR Software Testing Automation Research 8 7 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 一 連の動作の流れを共通化するための FlowDriver Class の作成 複数の PageDriver を保持し、 共通化するための関数を定義する
  84. STAR Software Testing Automation Research 8 8 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 PageDriver Class、PageFindable Class、FlowDriver Class のまとめ
  85. STAR Software Testing Automation Research 8 9 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 PageDriver Class、PageFindable Class、FlowDriver Class のまとめ アーキテクチャで縛る • PageDriver と PageFindable の役割を細分化することで、 コンポーネントの指定が明確になり、重複が排除される • FlowDriver の作成により、オンボーディングや認証などの フローを部分的に共通化することが可能に
  86. STAR Software Testing Automation Research 9 0 3 . 2

    . Robot Pattern の採 用 とコーディングルールの制定 PageDriver Class、PageFindable Class、FlowDriver Class のまとめ アーキテクチャで縛る コーディングルールで縛る • PageDriver と PageFindable の役割を細分化することで、 コンポーネントの指定が明確になり、重複が排除される • FlowDriver の作成により、オンボーディングや認証などの フローを部分的に共通化することが可能に • PageDriver と PageFindable は1対1の関係を徹底し、 PageDriver が別の Page の PageFindable を参照することを禁 止 した • PageFindable で指定しているコンポーネントが何か、 実装者以外に理解しにくいので、ドキュメントコメントの追加を ルール化した
  87. STAR Software Testing Automation Research 9 1 3 . 3

    . OS の UI 箇所を触れるようにする integration_test は Flutter 内部にはアクセス可能だが Native 部分へのアクセスができない integration_test はアプリを含む Flutter へのアクセスが可能で、 カスタマイズ性が 非 常に 高 い。しかし、 ネイティブの要素(例:iOS の許可ダイアログ、通知ダイアログ) へのアクセスはできない。これにより、通知の開封シナリオや Google 、 Facebook などの認証 SDK を利 用 した認証機能のシナリオ作成が 困難になる。同様に、Webview の操作も困難になる。 🚧 開発環境の画像になります
  88. STAR Software Testing Automation Research 9 2 3 . 3

    . OS の UI 箇所を触れるようにする Patrol を利 用 する Patrol は LeanCode 社によって開発された integration_test の拡張ライブラリ。 https://github.com/leancodepl/patrol OSの許可ダイアログはもちろん、 ホームボタンやダークモードの切り替えなど、 OSの機能の操作を可能にする。 詳細: https://patrol.leancode.co/native/feature-parity
  89. STAR Software Testing Automation Research 9 3 3 . 3

    . OS の UI 箇所を触れるようにする JavaScript の document.querySelector を使い、WebView へのアクセス WINTICKETでは、WebViewのパッケージに fl utter_inappwebview を採 用 している。 fl utter_inappwebview には evaluateJavascript() という関数があり、JavaScriptの実 行 が可能。 Special Thanks to https://github.com/mj-hd ❤ https://inappwebview.dev/docs/webview/javascript/injection
  90. STAR Software Testing Automation Research シナリオを書くべきか、書かないべきかの判断について Test Matrix のページで 言

    及した通り、シナリオごとに 見 ると、 高 い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 9 4 3.4. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選 手 の詳細画 面 • 利 用 規約などの機能を持たない画 面
  91. STAR Software Testing Automation Research シナリオを書くべきか、書かないべきかの判断について Test Matrix のページで 言

    及した通り、シナリオごとに 見 ると、 高 い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 9 5 3.4. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選 手 の詳細画 面 • 利 用 規約などの機能を持たない画 面 主な理由: • OS や端末によって動作に差異が 生 まれづらい • インタラクションがないので複雑なロジックを 持たないことが多い • ユーザーができることが少ないので不具合に 繋がりづらい
  92. STAR Software Testing Automation Research シナリオを書くべきか、書かないべきかの判断について Test Matrixのページで 言 及した通り、

    シナリオごとに 見 ると、 高 い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 9 6 3.4. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選 手 の詳細画 面 • 利 用 規約などの機能を持たない画 面 Low E ff ort High E ff ort High Con fi dence Low Con fi dence E 2 E Test E 2 E Test そもそも書けない ・ 書くのが難しいシナリオ →
  93. STAR Software Testing Automation Research シナリオを書くべきか、書かないべきかの判断について Test Matrixのページで 言 及した通り、

    シナリオごとに 見 ると、 高 い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 9 7 3.4. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選 手 の詳細画 面 • 利 用 規約などの機能を持たない画 面 Low E ff ort High E ff ort High Con fi dence Low Con fi dence E 2 E Test E 2 E Test そもそも書けない ・ 書くのが難しいシナリオ → 書く E 2 E Test 書かない E 2 E Test
  94. STAR Software Testing Automation Research 9 8 3.4. 機能別のシナリオ作成のやる ・

    やらないの判断基準、優先度を標準化 Test Case Prioritization を 用 いて評価指標を作成する 各シナリオの実施 ・非 実施を評価するために、それぞれに重み付けを 行 う。 この重み付けの項 目 を決定する際に、Test Case Prioritizationの考え 方 を参考にした。
  95. STAR Software Testing Automation Research 9 9 3.4. 機能別のシナリオ作成のやる ・

    やらないの判断基準、優先度を標準化 Test Case Prioritization (TCP) について コードカバレッジ、機能のリスクや重要性、コストなどの様々な要素に基づき、テストスイート内のテス トケースに優先順位をつけるプロセス。 TCP には多種多様な優先順位付けの考え 方 が存在する。 https://www.browserstack.com/guide/test-case-prioritization 🧠 Coverage-Based TCP Risk-Based TCP Requirements-Based TCP History-Based TCP Cost-Aware-Based TCP
  96. STAR Software Testing Automation Research WINTICKET で 採 用 したTest

    Case Prioritization たくさんの TCP が存在する中で 4 項 目 に絞り、各項 目 4段階の計16点で評価する。 売上へのリスク 事業信頼へのリスク 手 動検証にかかるコスト 実装コスト TCP 投票機能やチャージ機能など 金 銭に関わる機能ほど重い基準 ユーザーや公営競技主催者である地 方 公共団体の信 用 を失うリスクがあるかどうか 手 動検証にかかるシナリオほど 自 動化した時の価値が 高 いため 実装コストが 高 すぎるものはメンテコストや開発者のモチベーション低下に 繋がるため 概要 1 0 0 3.4. 機能別のシナリオ作成のやる ・ やらないの判断基準、優先度を標準化 https://www.browserstack.com/guide/test-case-prioritization Risk-Based TCP Risk-Based TCP Cost-Aware-Based TCP Cost-Aware-Based TCP
  97. STAR Software Testing Automation Research 1 0 1 3.5. 不安定なシナリオへの対応策

    E 2 E Test における不安定とは E 2 E Testは、その性質上、実際のAPIを叩くために結果の取得に時間がかかるケースや、タップや 入力 する 対象の要素の検出に失敗することが稀にある。 これらの不安定性を解消するための3つのアプローチを紹介する。
  98. STAR Software Testing Automation Research 1 0 2 3.5. 不安定なシナリオへの対応策

    1. 期待した Widget が表 示 されたかの確認には expect() ではなく 独 自 の拡張関数を利 用 する
  99. STAR Software Testing Automation Research 1 0 3 3.5. 不安定なシナリオへの対応策

    期待した Widget が表 示 されたかの確認には expect() ではなく 独 自 の拡張関数を利 用 する expect() だと実 行 のタイミングでそのコンポーネントの 有無で結果を決めてしまうが、waitFor() を使うことで 一 定時間待つことができる 一 定時間の間、コンポーネントを探し続け、 発 見 できなかった場合は TimeoutException を throw する
  100. STAR Software Testing Automation Research 1 0 5 3.5. 不安定なシナリオへの対応策

    画 面 遷移を待機する拡張関数の実装 Findable は 画 面 の Class を T とした BaseFindable を継承する waitUntilVisible() を作成し、 自身 のWidgetが表 示 されている ことを保証する関数を作っていく
  101. STAR Software Testing Automation Research 1 0 6 3.5. 不安定なシナリオへの対応策

    画 面 が表 示 されるまで待機することで 安定性の向上につながる
  102. STAR Software Testing Automation Research 1 0 7 3.5. 不安定なシナリオへの対応策

    https://cloud.google.com/sdk/gcloud/reference/ fi rebase/test/android/run#--num- fl aky-test-attempts 3 . Firebase Test Lab の num- fl aky-test-attempts を利 用 する WINTICKETでは、E 2 E Test の実 行 環境としてFirebase Test Labを使 用 している。 Firebase Test Labには実 行 時のオプションとして num- fl aky-test-attempts があり、 これを 用 いて上限回数を設定することができる。 設定した回数までシナリオを再実 行 し、全て失敗した場合のみテスト失敗と判定する。
  103. STAR Software Testing Automation Research 1 0 8 3 .

    6 . Hot Restart でのシナリオの実装を可能にする ローカル環境で fl utter drive を使 用 せず fl utter run で実 行 する E 2 E Test は、 fl utter run を使っても実 行 可能。 これにより、Hot Restart を 用 いた開発が可能となる。 この機能は Patrol v 1 . 1 でも利 用 可能。 また、類似のパッケージとして fl utter_convenient_test でも利 用 可能。
  104. STAR Software Testing Automation Research 1 0 9 3.7. 運

    用 時のシナリオの実 行 頻度やその 方 法 E 2 E Test の実 行 頻度について 当初はCommitごとの実 行 を理想としていたが、Commitごとのテストでは以下の問題が 生 じた 😫 テストが並列に実 行 されるため、 一 定数のテストアカウントを 用 意する必要がある 😫 競輪やオートレースのレースが開催されていない時間帯でもテストが実 行 される 😫 全シナリオの通しテストにかかる時間だけ、マージキューが蓄積し開発体験が低下する
  105. STAR Software Testing Automation Research 1 1 0 3.7. 運

    用 時のシナリオの実 行 頻度やその 方 法 E 2 E Test の実 行 頻度について 当初はCommitごとの実 行 を理想としていたが、Commitごとのテストでは以下の問題が 生 じた 😫 テストが並列に実 行 されるため、 一 定数のテストアカウントを 用 意する必要がある 😫 競輪やオートレースのレースが開催されていない時間帯でもテストが実 行 される 😫 全シナリオの通しテストにかかる時間だけ、マージキューが蓄積し開発体験が低下する これら全てに対応するのは困難と考え、 定期実 行 への切り替えを決断。 ↓
  106. STAR Software Testing Automation Research 1 1 1 3.7. 運

    用 時のシナリオの実 行 頻度やその 方 法 E 2 E Test の実 行 頻度について 最終的には以下の体制を採 用 • 毎 日 午前中に全てのシナリオを iOS / Android それぞれで実 行 • 全体のシナリオを半分に分けて2回にわけて実 行 • シナリオが失敗した時にはランダムでメンバーにメンション • OS の網羅性を担保するために、 午後には実 行 環境を変えて実 行 成功した時の Slack 通知例 失敗した時の Slack 通知例
  107. STAR Software Testing Automation Research 1 1 2 3.8. 随時追加される機能のシナリオをどのように担保するか

    E 2 E Test のシナリオ作成フローを機能開発時に組み込む QCチームと連携し、QCチームが作成した項 目 書をアプリチームに共有。 これをアプリチームのエンジニアがシナリオ実装の指針とし、シナリオの品質を担保する。 PR Unit Test VRT レビュー マージ QC リリース 🛠 🤖 👀 🧑🔧 ✈ シナリオ作成 E 2 E Test
  108. STAR Software Testing Automation Research 1. メリット 2. デメリット 3.

    まとめ 1 1 3 4. 自 動テストを安定するまで 運 用 してみて
  109. STAR Software Testing Automation Research 1 1 4 4.1. 自

    動テストを安定するまで運 用 してみて - メリット • 事前にエラー ・ デグレを検知し、障害を未然に防ぐことができている ✅ • SkSLの 自 動 生 成が可能 📲 • 実際のAPIを使 用 するため、ユニットテストでは検知できないエラーを発 見 できる 👀 • アプリだけでなく、Server のデグレ検知にもつながる💻 • 初期の段階では効果を感じにくいが、 長 期的にはリソースの節約につながる 📈 メリット
  110. STAR Software Testing Automation Research 1 1 5 4.1. 自

    動テストを安定するまで運 用 してみて - メリット 障害を未然に防いた実例 • FlutterFire の Version 更新に伴う認証基盤のデグレ • Server の デグレ検知 • 新機能開発時の考慮漏れ メリット
  111. STAR Software Testing Automation Research 1 1 6 4.1. 自

    動テストを安定するまで運 用 してみて - デメリット • 機能作成時にシナリオ作成が必要となり、リソースを圧迫する 😫 • エンジニアのシナリオ作成の学習コスト 高 い 👨🎓 • Robot Pattern や E 2 E Test の実装に馴染みのないエンジニアが多い • 既存のアプリ内で特定の画 面 やコンポーネントを探すのに 手 間がかかる • テストが失敗した場合、他の作業を優先せず修復にあたる必要があり、メンテナンスコストが 高 い • 初期導 入 のコストが 高 い 🔧 • 費 用 がかかる💰 デメリット
  112. STAR Software Testing Automation Research 1 1 7 4.1. 自

    動テストを安定するまで運 用 してみて - デメリット 以下の内容が今後の注 力 ポイントになると考えています。 • 自 動テストが落ちた時により素早く修正できる状態 ・文 化の形成が必要 🧑🎓 • シナリオ数の増加に伴う 自 動テストの実 行 の並列化や 高 速化 🔄 今後
  113. STAR Software Testing Automation Research 1 1 8 4.3. 自

    動テストを安定するまで運 用 してみて - まとめ • 自 動テストの導 入 にはツールの選定、運 用 体制の構築に 至 るまで、全ての段階でプロダクトの現状分析 が重要 📈 • 自 動テストにより事前に障害を検知することが可能だが、その効果を実感するまでには時間がかかる ⏰ • Flutter での E 2 E Test は学習コストが 高 いものの、便利なツールが次々と登場している 🔥 • WINTICKET では、今後もシナリオを増やし、より堅牢かつ、メンテナンス性の 高 い体制を 構築していく予定 🏃 まとめ
  114. STAR Software Testing Automation Research 1 1 9 4.3. 自

    動テストを安定するまで運 用 してみて - まとめ メリットもデメリットもたくさんに存在しますが、最も難しかったのは「E 2 E Test をアプリチーム全体で 理解し、このツールを継続的にメンテナンスしていく意識を持ってもらうこと」でした。 幸運なことに、私は協 力 的なチームメンバーに恵まれ、初期段階から積極的にシナリオの追加や継続的な メンテナンスに協 力 してもらえました。本当に感謝しています 🙇 感想