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

Flutter アプリにおけるテスト戦略の見直しと自動テストの導入

Takuma Osada
November 09, 2023

Flutter アプリにおけるテスト戦略の見直しと自動テストの導入

2023/11/10 に開催されたFlutterKaigi 2023での登壇資料です
https://flutterkaigi.jp/2023/sessions/df52c995-5fbb-4ff0-abbc-e6332af98797

私たちのチームは、品質維持を目指してテスト戦略の見直しを行い、その結果、integration_testを用いた自動テストの導入に至りました。
これまで一年間の運用を通じて、自動テストのシナリオ数は40を超え、その過程で多くの課題と学びがありました。

具体的には、以下のような問いに対する答えを探求しました。

自動テストを実行する最適なフローとタイミングは何か
成熟したプロジェクトにおいて、どの機能から自動テストを導入すべきか
自動テストを実施するか否かの判断基準は何か
不安定なテストシナリオにどのように対処すべきか
AutifyやMaestroなどの他のツールと比較して、何が違うのか
私たちがこれらの課題にどのように取り組み、何を学んだのかを共有します。さらに、以下の観点からも話を進めます。

テスト戦略を見直すことになった背景と動機
テスト戦略の見直しから自動テスト選定までのプロセス
自動テスト導入による得られた利益とデメリット
本トークは、Flutterとintegration_testを使用したプロジェクトの事例を中心に話しますが、その内容はモバイルアプリ全般の開発に役立つ情報を提供します。

想定視聴者
Flutter開発で自動テストに興味がある方
プロダクト開発において自動テストの運用を検討中の方

Takuma Osada

November 09, 2023
Tweet

More Decks by Takuma Osada

Other Decks in Programming

Transcript

  1. FlutterKaigi 2023 2 ⾃⼰紹介 ⻑⽥ 卓⾺ 株式会社サイバーエージェント 21年度新卒⼊社 Flutter Engineer

    マイブームはバズレシピ系 YouTuber の動画⾒ながらの料理 • GitHub ID: ostk 0 0 6 9 • X ID: ostk 0 0 6 9
  2. FlutterKaigi 2023 WINTICKET の歴史 1 0 1.1. テスト戦略⾒直しの背景 現在 2

    0 2 3 / 1 1 2 0 2 3 2 0 2 2 2 0 2 3 / 3 iOS リプレース 2 0 2 2 / 3 Android リプレース TWA → →
  3. FlutterKaigi 2023 1 1 1.1. テスト戦略⾒直しの背景 👨💻 👨💻 👨💻 👨💻

    👨💻 👨💻 👨💻 機能開発チーム SREチーム アプリチーム 機能開発をメインに担当 CI/CDや基盤など 機能開発以外を担当
  4. FlutterKaigi 2023 1 2 1.1. テスト戦略⾒直しの背景 👨💻 👨💻 👨💻 👨💻

    👨💻 👨💻 👨💻 機能開発チーム SREチーム アプリチーム 機能開発をメインに担当 CI/CDや基盤など機能開発以外を担当 SRE チームの 2023 年のミッション 「アプリの可⽤性を向上させる」 👨💻 👨💻 👨💻
  5. FlutterKaigi 2023 1 3 1.1. テスト戦略⾒直しの背景 可⽤性とは... 可⽤性 (%) =

    稼働時間 / (停⽌時間 + 稼働時間) 停⽌時間 (h) = 平均修復時間* x 3 6 5 ⽇ x 2 4 時間 / 平均故障間隔* 平均修復時間 = 停⽌時間の合計 / 失敗の回数 平均故障間隔 = 稼働時間の合計 / 失敗の回数
  6. FlutterKaigi 2023 1 4 1.1. テスト戦略⾒直しの背景 2022 年の状況 • 変更障害率:

    7.5 % (3/40) • 平均停⽌時間: 4.0 ⽇ • 可⽤性: 96.8 %
  7. FlutterKaigi 2023 1 5 1.1. テスト戦略⾒直しの背景 2022 年の状況 • 変更障害率:

    7.5 % (3/40) • 平均停⽌時間: 4.0 ⽇ • 可⽤性: 96.8 % 2023 年の⽬標 • 変更障害率: 5 % • 平均停⽌時間: 3.0 ⽇ • 可⽤性: 98.4 % →
  8. FlutterKaigi 2023 ⽬標を達成するために 1 6 1.1. テスト戦略⾒直しの背景 📈 平均障害率を下げる 🕐

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

    🕐 平均修復時間を下げる • リリース前に問題を検知できる体制づくり • 既存のテスト体制の⾒直しを実施する • リリース後に不具合を早期に検知したい • 既存のモニタリング体制の⾒直しを実施する
  10. FlutterKaigi 2023 1 8 1.2. 既存のテスト体制を把握する テストピラミッドについて End to End

    Test Integration Test Unit Test Manual Test Manual Test: ⼿動で機能が正常に動くか End to End Test: シナリオを形成し、機能単位で 
 アプリケーションが期待通りに実⾏されるか Integration Test: 複数のユニットが期待通りに実⾏されるか Unit Test: 単⼀クラスや関数が期待通りに実⾏されるか
  11. FlutterKaigi 2023 1 9 1.2. 既存のテスト体制を把握する WINTICKET の 2022 年

    8 ⽉のテスト体制 End to End Test Integration Test Unit Test Manual Test Manual Test: QC、リリース前にアプリチームでの検証 End to End Test: 試験的に導⼊したシナリオがひとつ Integration Test: なし Unit Test: レイヤーによってカバレッジが⾼い箇所と 
 低い箇所が存在する
  12. FlutterKaigi 2023 2 0 1.2. 既存のテスト体制を把握する 🤔 Unit Test の拡充を進めるか…

    E 2 E Test の拡充を進めるか… 全く新しい道を模索するか… (そんなものはあるのか…?)
  13. FlutterKaigi 2023 2 1 1.2. 既存のテスト体制を把握する 🤔 Unit Test の拡充を進めるか…

    E 2 E Test の拡充を進めるか… 全く新しい道を模索するか… (そんなものはあるのか…?) 過去の障害事例から注⼒ポイントを⾒つける 👀
  14. FlutterKaigi 2023 2 2 1.3. 過去のインシデントから改善点を把握する 2022 年に障害が起きた Pull Request

    を分別する(⼤⼩問わず 9 件からまとめたもの) 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に⾒つけられなかった 不具合や仕様の考慮漏れ Renovate や Dependabot による Package の依存更新時の不具合 既存のコードの改修から発⽣する不具合 既存からある機能の不具合の改修に伴う 副作⽤から発⽣する不具合 Feature Flag の利⽤ 発⽣件数 2 件 5 件 1 件 テスターによる 
 QC の有無 ✅ ❌ ❌ ❌ ✅ ✅ ❌ ❌ 1 件
  15. FlutterKaigi 2023 2022 年に障害が起きた Pull Request を分別する(⼤⼩問わず 9 件からまとめたもの) 2

    3 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング 不具合修正 概要 機能開発時に⾒つけられなかった 不具合や仕様の考慮漏れ 既存のコードの改修から発⽣する不具合 既存からある機能の不具合の改修に伴う 副作⽤から発⽣する不具合 ✅ ❌ Feature Flag の利⽤ 発⽣件数 1 件 2 件 5 件 1 件 ❌ ❌ ✅ ✅ ❌ ❌ テスターによる 
 QC の有無 QC を実施しておらず、注⼒ポイントになりそう👊 Renovate や Dependabot による Package の依存更新時の不具合
  16. FlutterKaigi 2023 起きた障害に対するテストの種別ごとに導⼊した際の効果 2 4 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング

    不具合修正 VRT - Unit Test Integration Test E 2 E Test - 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです 中 ⼩ 中 中 ⼩ 中 中 ⼩ ⼩ ⼩ ⼤ ⼤ ⼤ 中
  17. FlutterKaigi 2023 起きた障害に対するテストの種別ごとに導⼊した際の効果 2 5 1.3. 過去のインシデントから改善点を把握する 機能開発 依存更新 リファクタリング

    不具合修正 VRT ⼤ - Unit Test Integration Test E 2 E Test ⼤ ⼤ 中 - 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです 中 ⼩ 中 中 ⼩ ⼩ ⼩ 中 ⼩ 中 他のテスト⼿法よりも不具合防⽌の効果が⾼い📈
  18. FlutterKaigi 2023 現在(2022 年 8 ⽉)と注⼒した場合の差分を挙げる 2 6 1.3. 過去のインシデントから改善点を把握する

    現在の網羅率 追加コスト VRT Unit Test Integration Test E 2 E Test 5 0 % 追加時の効果 9 0 % ~ 0 % 5 % ⼩ ~ 中 ⼩ 中 ~ ⼤ 中 ~ ⼤ ⼤ ⼩ ⼩ ⼩ 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです
  19. FlutterKaigi 2023 現在(2022 年 8 ⽉)と注⼒した場合の差分を挙げる 2 7 1.3. 過去のインシデントから改善点を把握する

    現在の網羅率 追加コスト VRT Unit Test Integration Test E 2 E Test 追加時の効果 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです 5 0 % 9 0 % ~ 5 % ⼩ ~ 中 ⼩ 中 ~ ⼤ 中 ~ ⼤ ⼤ ⼩ ⼩ ⼩ 0 % 追加コストは⼤きいが、その分効果も期待できる💪
  20. FlutterKaigi 2023 2 8 1.3. 過去のインシデントから改善点を把握する まとめ 次の理由から、E 2 Eテストの強化に注⼒する

    ✅ 他のテスト⼿法に⽐べ、問題が多く発⽣する箇所(依存性の更新、リファクタリング、バグ修正)への 対策が期待できる ✅ 追加コストは⾼いが、まだ網羅していない機能が多く、導⼊後の効果が⼤いに期待できる
  21. FlutterKaigi 2023 3 0 2.1. プロダクトに合うツール選定を⾏う ⾃動テストのツールの種類 • SaaS ツールを利⽤する

    Eg: Autify for Mobile、MagicPod … • OSS ツールを利⽤する Eg: Appium、Maestro … • Plaform が提供しているツールを利⽤する Eg: integration_test、XCTest、Espresso …
  22. FlutterKaigi 2023 3 1 2.1. プロダクトに合うツール選定を⾏う ⾃動テストのツールの⽐較 - Autify for

    Mobile ノーコードを使ったソフトウェアテスト⾃動化プラットフォーム。 https://autify.com/ja/mobile 2023 年 2 ⽉に Android に正式対応。プラットフォーム依存しないため、 
 Flutter 以外の iOS、Android、React Native での実⾏も可能。 
 社内での利⽤実績あり、WINTICKET でも Web で利⽤中。 
 選定にあたり、実際にトライアルで検証を⾏った。
  23. FlutterKaigi 2023 3 2 2.1. プロダクトに合うツール選定を⾏う ⾃動テストのツールの⽐較 - Maestro シナリオ作成の⾔語として

    Yaml を採⽤したUIテストツール。 https://maestro.mobile.dev プラットフォーム依存しないため、Flutter 以外の iOS、 Android、React Native でも実⾏可能。 Yamlを採⽤することで、シンプルな記述でシナリオ作成が 可能となる。このツールは、"Maestro Cloud” と呼ばれる環境下で 実⾏可能。 ⚠ Maestro Cloud 上での実機での実⾏のサポートは現在なし
  24. FlutterKaigi 2023 3 3 2.1. プロダクトに合うツール選定を⾏う ⾃動テストのツールの⽐較 - integration_test Flutter

    公式から提供されるテストツールで、iOS の XCTest や Android のEspresso と同等の位置づけ。 https://docs. fl utter.dev/testing/integration-tests 記述はDartのみ可能。 初回のパフォーマンス向上を⽬的としたSkSL⽣成に、 実⾏シナリオを利⽤可能。
  25. FlutterKaigi 2023 3 4 2.1. プロダクトに合うツール選定を⾏う ツールに求める要件 🚧 開発環境の画像になります MUST

    • 頻繁に状態がかわる UI への対応⼒ • 多種多様な環境での実⾏可能性 BETTER • エンジニアのシナリオ作成コストが低い • 運⽤にかかる費⽤が安い 💰
  26. FlutterKaigi 2023 3 5 2.1. プロダクトに合うツール選定を⾏う WINTICKET がツールに求める要件 頻繁に状態がかわる UI

    への対応⼒ 多種多様な環境での実⾏可能性 エンジニアのシナリオ作成コストが低い 運⽤にかかる費⽤が安い Autify for Mobile Maestro integration_test 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです ❌ ✅ ✅ ❌ ❌ ✅ 🤔 ✅ ❌ ✅ ❌ ✅
  27. FlutterKaigi 2023 3 6 2.1. プロダクトに合うツール選定を⾏う WINTICKET がツールに求める要件 頻繁に状態がかわる UI

    への対応⼒ エンジニアのシナリオ作成コストが低い 運⽤にかかる費⽤が安い Autify for Mobile ❌ Maestro integration_test 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです ❌ 🤔 ✅ ❌ ✅ ❌ ✅ ❌ ✅ ✅ ✅ 作成コストは⼤きいが、他の条件を満たしている✅ 多種多様な環境での実⾏可能性
  28. FlutterKaigi 2023 3 7 2.1. プロダクトに合うツール選定を⾏う WINTICKET がツールに求める要件 頻繁に状態がかわる UI

    への対応⼒ 多種多様な実⾏環境での実⾏可能性 エンジニアのシナリオ作成コストが低い 運⽤にかかる費⽤が安い Autify for Mobile ❌ Maestro integration_test - 🚧 2022 年 8 ⽉当時の WINTICKET のアプリチーム独⾃の判断によるものです ❌ 🤔 ✅ ❌ ✅ ❌ ✅ ❌ ✅ ✅ ✅ 作成コストは⼤きいが、他の条件を満たしている✅ integration_test を⾃動テストのツールとして採⽤ 😎
  29. FlutterKaigi 2023 3 8 2.2. テスターによる⼿動テストとの差別化 🧑💻 「E 2 E

    Test は⼿動 QC の⾃動化をゴールにやるんですか?」 A.「やりません🙅」
  30. FlutterKaigi 2023 3 9 2.2. テスターによる⼿動テストとの差別化 WINTICKET の QC 体制

    変更差分のない コード 依存 Package の更新 新機能の 
 コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし ❌ QC 実施なし
  31. FlutterKaigi 2023 4 0 2.2. テスターによる⼿動テストとの差別化 WINTICKET の QC 体制

    変更差分のない コード 依存 Package の更新 新機能の 
 コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし Flutter のバージョン更新、 FlutterFire や、RiverPod などの ⼤きな依存は全機能 QC を実施 ✅ ✅ QC 実施
  32. FlutterKaigi 2023 4 2 2.2. テスターによる⼿動テストとの差別化 テスターによる⼿動テストとの差別化 変更差分のない コード 依存

    Package の更新 新機能の 
 コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ❌ QC 実施なし ❌ QC 実施なし
  33. FlutterKaigi 2023 4 3 2.2. テスターによる⼿動テストとの差別化 テスターによる⼿動テストとの差別化 変更差分のない コード 依存

    Package の更新 新機能の 
 コード アプリケーションコード全体 → → 開発 🧑💻 ✅ QC 実施 ✅ E 2 E Test でカバーする
  34. FlutterKaigi 2023 4 4 2.2. テスターによる⼿動テストとの差別化 メリット • 新機能開発のリソースを⾃動テストのシナ リオ作成でひっ迫させない

    • ⾃動テストによる精度の限界を 
 ⼿動テストでカバー デメリット • シナリオ作成を忘れてしまう • ⾃動テストでテスターさんの 
 検証コストをカバーできていない
  35. FlutterKaigi 2023 4 5 2.2. テスターによる⼿動テストとの差別化 メリット • 新機能開発のリソースを⾃動テストのシナ リオ作成でひっ迫させない

    • ⾃動テストによる精度の限界を 
 ⼿動テストでカバー デメリット • シナリオ作成を忘れてしまう • ⾃動テストでテスターさんの 
 検証コストをカバーできていない フロー化することでカバー ⾃動テストの精度がテスターさんによる 
 ⼿動検証の精度を上回るのは無理だと判断
  36. FlutterKaigi 2023 4 6 2.2. テスターによる⼿動テストとの差別化 メリット • ⾃動テストのシナリオ作成が 


    機能開発のリソースをひっ迫させない • ⾃動テストによる精度の限界を 
 ⼿動テストでカバー デメリット • シナリオ作成を忘れてしまう • ⾃動テストのシナリオでテスターさんの 
 検証コストをカバーできていない フロー化することでカバー ⾃動テストの品質がテスターさんによる 
 ⼿動検証の品質を上回るのは無理だと判断 E 2 E Test は QC の⾃動化をせず、QC と並⾛して、 QC の範囲外の項⽬でのデグレ検知を⽬的として利⽤ 🤝
  37. FlutterKaigi 2023 4 7 3. ⾃動テストの シナリオ拡張期‧運⽤期について 1 . Test

    Matrix から注⼒ポイントを分析する 2 . Robot Pattern の採⽤とコーディングルールの制定 3 . OS の UI 箇所を触れるようにする 4. 機能別のシナリオ作成のやる‧やらないの 判断基準、優先度を標準化 5. 不安定なシナリオへの対応策 6 . Hot Restart でのシナリオの実装を可能にする 7. 運⽤時のシナリオの実⾏頻度やその⽅法 8. 随時追加される機能のシナリオを どのように担保するか
  38. FlutterKaigi 2023 Test Matrix とは ... E ff ort (テストに必要な労⼒)

    と Con fi dence (テスト実⾏による信頼性) を図⽰したものです。 4 8 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
  39. FlutterKaigi 2023 Test Matrix とは ... E ff ort (テストに必要な労⼒)

    と Con fi dence (テスト実⾏による信頼性) を図⽰したものです。 4 9 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
  40. FlutterKaigi 2023 5 0 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 • インストール: テストが実⾏できる環境の準備 • 作成: テスト作成の難易度や所要時間 • 実⾏: テスト スイートの実⾏にかかる時間 • デバッグ: 失敗時に問題の特定と修正のしやすさ • メンテナンス: 維持するために必要なコスト テストがもたらすアプリケーションの信頼性
  41. FlutterKaigi 2023 5 1 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
  42. FlutterKaigi 2023 5 2 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
  43. FlutterKaigi 2023 5 3 3 . 1 . Test Matrix

    から注⼒ポイントを分析する Test Matrix の考え⽅を応⽤する WINTICKETの2022 年 11 ⽉時点の 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
  44. FlutterKaigi 2023 5 4 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
  45. FlutterKaigi 2023 5 5 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 そもそも書けない‧書くのが難しいシナリオ →
  46. FlutterKaigi 2023 5 6 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
  47. FlutterKaigi 2023 5 7 3 . 1 . Test Matrix

    から注⼒ポイントを分析する Test Matrix の考え⽅を応⽤する Unit Test / VRT Test の現時点の考え • ✅ インストール: 初期からの変化はなし • 🤔 作成: 投票の裏側のロジックなど複雑なものも存在する • ❌ 実⾏: テストケース増加で実⾏時間が伸びている • ❌ デバッグ: テストケース増加に伴う複雑さの増加 • ✅ メンテナンス: 単⼀テストのため、疎結合になっている https://portal.gitnation.org/contents/testing-pyramid-makes-little-sense-what-we-can-use-instead 
 https://semaphoreci.com/blog/testing-pyramid
  48. FlutterKaigi 2023 5 8 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
  49. FlutterKaigi 2023 5 9 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 特に改善に繋がりそうな 「作成」「実⾏」「デバッグ」 への改善策を考える
  50. FlutterKaigi 2023 6 0 3 . 1 . Test Matrix

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

    から注⼒ポイントを分析する • 実⾏が不安定なシナリオが存在する → 3.6. 不安定なシナリオへの対応策 • Hot Restart が使⽤できないため、問題の検出に⼿間がかかる → 3 . 7 . Hot Restart でのシナリオの実装を可能にする 「実⾏」の E ff ort の課題 「デバッグ」の E ff ort の課題
  52. FlutterKaigi 2023 6 2 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/
  53. FlutterKaigi 2023 6 3 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 を利⽤した実装を⽐較していく 👀
  54. FlutterKaigi 2023 6 4 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/
  55. FlutterKaigi 2023 6 5 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” の⽂字が⾒えるか照合
  56. FlutterKaigi 2023 6 6 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/
  57. FlutterKaigi 2023 6 7 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 する形で それぞれのアクション関数を作成
  58. FlutterKaigi 2023 6 8 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 を宣⾔し、 その後アクション関数を呼び出す
  59. FlutterKaigi 2023 6 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/ コード量⾃体はあまり変化はないが、 可読性が上がっているのがわかる 👀
  60. FlutterKaigi 2023 7 0 3 . 2 . Robot Pattern

    の採⽤とコーディングルールの制定 E 2 E Testのデザインパターン - Robot Pattern 最終的に Robot Pattern の考えをベースに以下の形で落ち着いた • Robot Class を PageDriver Class と PageFindable Class に分割 • 認証やオンボーディング画⾯などの⼀連の動作の流れを共通化するための FlowDriver Class を作成
  61. FlutterKaigi 2023 7 1 3 . 2 . Robot Pattern

    の採⽤とコーディングルールの制定 Robot Class を PageDriver Class と PageFindable Class に分割
  62. FlutterKaigi 2023 7 2 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
  63. FlutterKaigi 2023 7 3 3 . 2 . Robot Pattern

    の採⽤とコーディングルールの制定 ⼀連の動作の流れを共通化するための FlowDriver Class の作成
  64. FlutterKaigi 2023 7 4 3 . 2 . Robot Pattern

    の採⽤とコーディングルールの制定 ⼀連の動作の流れを共通化するための FlowDriver Class の作成 複数の PageDriver を保持し、 共通化するための関数を定義する
  65. FlutterKaigi 2023 7 5 3 . 2 . Robot Pattern

    の採⽤とコーディングルールの制定 PageDriver Class、PageFindable Class、FlowDriver Class のまとめ
  66. FlutterKaigi 2023 7 6 3 . 2 . Robot Pattern

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

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

    UI 箇所を触れるようにする Patrol を利⽤する Patrol は LeanCode 社によって開発された integration_test の拡張ライブラリ。 
 https://github.com/leancodepl/patrol OSの許可ダイアログはもちろん、 ホームボタンやダークモードの切り替えなど、 OSの機能の操作を可能にする。 詳細: https://patrol.leancode.co/native/feature-parity
  69. FlutterKaigi 2023 7 9 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
  70. FlutterKaigi 2023 8 1 3.3.1. メールリンクログイン機能を実装する 外部ツールを利⽤して裏側でメールリンクの開封を⾏う MailSlurp や Gmail

    Web API を利⽤すれば、送信されたメールをAPI経由で取得し、メール内のリンク URL を開くことが可能。これにより、メールアプリを介さずにメールリンク認証を完了することができる。 WINTICKET では、無料で利⽤できる Gmail Web API を採⽤している。 https:// fi rebase.google.com/docs/auth/ fl utter/email-link-auth?hl=ja 
 https://support.magic-pod.com/hc/ja/articles/ 4 4 0 8 9 1 0 3 9 8 6 1 7 -Email%E 3 % 8 1 %AE%E 3 % 8 3 % 8 6 %E 3 % 8 2 %B 9 %E 3 % 8 3 % 8 8
  71. FlutterKaigi 2023 シナリオを書くべきか、書かないべきかの判断について Test Matrix のページで⾔及した通り、シナリオごとに⾒ると、⾼い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 8 2 3.4.

    機能別のシナリオ作成のやる‧やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選⼿の詳細画⾯ • 利⽤規約などの機能を持たない画⾯
  72. FlutterKaigi 2023 シナリオを書くべきか、書かないべきかの判断について Test Matrix のページで⾔及した通り、シナリオごとに⾒ると、⾼い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 8 3 3.4.

    機能別のシナリオ作成のやる‧やらないの判断基準、優先度を標準化 High Con fi dence に繋がりにくいシナリオ例: • ユーザーが閲覧することしかできない競輪選⼿の詳細画⾯ • 利⽤規約などの機能を持たない画⾯ 主な理由: • OS や端末によって動作に差異が⽣まれづらい • インタラクションがないので複雑なロジックを 
 持たないことが多い • ユーザーができることが少ないので不具合に 
 繋がりづらい
  73. FlutterKaigi 2023 シナリオを書くべきか、書かないべきかの判断について Test Matrixのページで⾔及した通り、 シナリオごとに⾒ると、⾼い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 8 4 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 そもそも書けない‧書くのが難しいシナリオ →
  74. FlutterKaigi 2023 シナリオを書くべきか、書かないべきかの判断について Test Matrixのページで⾔及した通り、 シナリオごとに⾒ると、⾼い信頼性につながる シナリオと、それにつながりにくいシナリオが存在する。 8 5 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
  75. FlutterKaigi 2023 8 6 3.4. 機能別のシナリオ作成のやる‧やらないの判断基準、優先度を標準化 Test Case Prioritization を⽤いて評価指標を作成する

    各シナリオの実施‧⾮実施を評価するために、それぞれに重み付けを⾏う。 この重み付けの項⽬を決定する際に、Test Case Prioritizationの考え⽅を参考にした。
  76. FlutterKaigi 2023 8 7 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
  77. FlutterKaigi 2023 WINTICKET で 採⽤したTest Case Prioritization たくさんの TCP が存在する中で

    4 項⽬に絞り、各項⽬4段階の計16点で評価する。 売上へのリスク 事業信頼へのリスク ⼿動検証にかかるコスト 実装コスト TCP 投票機能やチャージ機能など⾦銭に関わる機能ほど重い基準 ユーザーや公営競技主催者である地⽅公共団体の信⽤を失うリスクがあるかどうか ⼿動検証にかかるシナリオほど⾃動化した時の価値が⾼いため 実装コストが⾼すぎるものはメンテコストや開発者のモチベーション低下に 繋がるため 概要 8 8 3.4. 機能別のシナリオ作成のやる‧やらないの判断基準、優先度を標準化 https://www.browserstack.com/guide/test-case-prioritization Risk-Based TCP Risk-Based TCP Cost-Aware-Based TCP Cost-Aware-Based TCP
  78. FlutterKaigi 2023 8 9 3.5. 不安定なシナリオへの対応策 E 2 E Test

    における不安定とは E 2 E Testは、その性質上、実際のAPIを叩くために結果の取得に時間がかかるケースや、タップや⼊⼒する 対象の要素の検出に失敗することが稀にある。 これらの不安定性を解消するための3つのアプローチを紹介する。
  79. FlutterKaigi 2023 9 1 3.5. 不安定なシナリオへの対応策 期待した Widget が表⽰されたかの確認には expect()

    ではなく 独⾃の拡張関数を利⽤する expect() だと実⾏のタイミングでそのコンポーネントの 有無で結果を決めてしまうが、waitFor() を使うことで ⼀定時間待つことができる ⼀定時間の間、コンポーネントを探し続け、 
 発⾒できなかった場合は TimeoutException を throw する
  80. FlutterKaigi 2023 9 3 3.5. 不安定なシナリオへの対応策 画⾯遷移を待機する拡張関数の実装 Findable は 画⾯の

    Class を T とした 
 BaseFindable を継承する waitUntilVisible() を作成し、 
 ⾃⾝のWidgetが表⽰されている 
 ことを保証する関数を作っていく
  81. FlutterKaigi 2023 9 5 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 があり、 
 これを⽤いて上限回数を設定することができる。 
 設定した回数までシナリオを再実⾏し、全て失敗した場合のみテスト失敗と判定する。
  82. FlutterKaigi 2023 9 6 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 でも利⽤可能。
  83. FlutterKaigi 2023 9 7 3.7. 運⽤時のシナリオの実⾏頻度やその⽅法 E 2 E Test

    の実⾏頻度について 当初はCommitごとの実⾏を理想としていたが、Commitごとのテストでは以下の問題が⽣じた 😫 テストが並列に実⾏されるため、⼀定数のテストアカウントを⽤意する必要がある 😫 競輪やオートレースのレースが開催されていない時間帯でもテストが実⾏される 😫 全シナリオの通しテストにかかる時間だけ、マージキューが蓄積し開発体験が低下する
  84. FlutterKaigi 2023 9 8 3.7. 運⽤時のシナリオの実⾏頻度やその⽅法 E 2 E Test

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

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

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

    1 4. ⾃動テストを安定するまで 運⽤してみて
  88. FlutterKaigi 2023 1 0 2 4.1. ⾃動テストを安定するまで運⽤してみて - メリット •

    事前にエラー‧デグレを検知し、障害を未然に防ぐことができている ✅ • SkSLの⾃動⽣成が可能 📲 • 実際のAPIを使⽤するため、ユニットテストでは検知できないエラーを発⾒できる 👀 • App だけでなく、Server のデグレ検知にもつながる💻 • 初期の段階では効果を感じにくいが、⻑期的にはリソースの節約につながる 📈 メリット
  89. FlutterKaigi 2023 1 0 3 4.1. ⾃動テストを安定するまで運⽤してみて - メリット 障害を未然に防いた実例

    • FlutterFire の Version 更新に伴う認証基盤のデグレ • Server の デグレ検知 • 新機能開発時の考慮漏れ メリット
  90. FlutterKaigi 2023 1 0 4 4.1. ⾃動テストを安定するまで運⽤してみて - デメリット •

    機能作成時にシナリオ作成が必要となり、リソースを圧迫する 😫 • エンジニアのシナリオ作成の学習コスト⾼い 👨🎓 • Robot Pattern や E 2 E Test の実装に馴染みのないエンジニアが多い • 既存のアプリ内で特定の画⾯やコンポーネントを探すのに⼿間がかかる • テストが失敗した場合、他の作業を優先せず修復にあたる必要があり、メンテナンスコストが⾼い • 初期導⼊のコストが⾼い 🔧 • 費⽤がかかる💰 デメリット
  91. FlutterKaigi 2023 1 0 5 4.3. ⾃動テストを安定するまで運⽤してみて - まとめ •

    ⾃動テストの導⼊にはツールの選定、運⽤体制の構築に⾄るまで、全ての段階でプロダクトの現状分析 が重要 📈 • ⾃動テストにより事前に障害を検知することが可能だが、その効果を実感するまでには時間がかかる ⏰ • Flutter での E 2 E Test は学習コストが⾼いものの、便利なツールが次々と登場している 🔥 • WINTICKET では、今後もシナリオを増やし、より堅牢な体制を構築していく予定 🏃 まとめ
  92. FlutterKaigi 2023 1 0 6 4.3. ⾃動テストを安定するまで運⽤してみて - まとめ メリットもデメリットもたくさんに存在しますが、最も難しかったのは「E

    2 E Test をアプリチーム全体で 理解し、このツールを継続的にメンテナンスしていく意識を持ってもらうこと」でした。 幸運なことに、私は協⼒的なチームメンバーに恵まれ、初期段階から積極的にシナリオの追加や継続的な メンテナンスに協⼒してもらえました。本当に感謝しています 🙇 感想
  93. FlutterKaigi 2023 1 0 8 宣伝 また、WINTICKET のチームメンバー & 同期の

    batch より登壇があります。よければ発表をお聞きくださ い。 https:// fl utterkaigi.jp/ 2 0 2 3 /sessions/ 0 9 0 ad 5 b 8 - 7 0 6 6 - 4 0 e 6 - 8 ca 8 - 5 8 ff f 7 6 6 f 0 4 6