はじめに
こんにちは、Amebaマンガでモバイルエンジニアをしている内定者バイトの成尾 嘉貴（@naruogram）です。Amebaマンガの取り組みの一環として、E2Eテストの導入しました。
本記事では、FlutterアプリにおいてのE2Eテスト導入までの流れについてご紹介させていただきます。
※ 本記事では、個人的見解であり、特定のサービスを優遇するものではありません
目次
1. なぜE2Eテストを導入検討をしたのか
弊チームがE2Eテスト導入する理由は大きく二つあります。
1. 手動テストによる時間とコストの負担を軽減
大規模なリリースや中規模のリリースの度に手動でテストを行うと、それには多大な時間とコストがかかります。これを少しずつでも削減していくことで、より効率的な開発プロセスを実現したいと考えています。
2. デグレの解消を通じて、障害を防ぐ
新規機能の追加やリファクタリング、リアーキテクチャなどを行う際には、必然的にデグレが発生する可能性があります。弊チームはこれをリリース前に早期に発見し、品質を維持したいという意図があります。
2. FlutterアプリでのE2Eテストの選択肢について
FlutterアプリでE2Eテストを実現するには、下記のツールがあります。
- Flutter Integration Test
- Maestro
- MagicPod
- Autify
それぞれの特徴を説明していきます。
Flutter Integration Test
Flutter Integration Testは、Flutter標準のテスト機能です。
特徴は2点あります。
- Dartを使って書くことができる
- SharedPreferencesの値を変更や、Providerの値を更新することができるので柔軟なテストを作成することができる
Maestro
Maestroは、2022年9月にリリースされたE2Eテストツールです。
特徴は2点あります。
- yamlベースでテストケースを記述することができる
- シンプルなテストフレームワーク
MagicPod
MagicPodは、AIを活用したノーコード自動化テストツールです。
特徴は3点あります。
- GUIかつコマンドを使用し、テストケースを作成可能
- Appiumを使用しており、適切なロケーターの選択をすることができる
- SemanticsNodeを使用して、UI要素の発見(アサーション)を改善することができる
Autify
Autifyは、MagicPodと同様にAIを活用したノーコード自動化テストツールです。
特徴は2点あります。
- GUIで誰でも簡単に作成することができる
- MLタップという機械学習を用いた、テストケースの作成ができる
3. チームに最適なツール選定について
E2Eテスト導入で重要な観点としてツール選定が挙げられます。
ツール選定は、様々な要素からチームに合ったものを選ぶ必要があります。
今回は、弊チームでの実際に使用した選定基準について紹介させていただきます。
選定基準
1. エンジニアリソース
2. テストの安定性
3. 金銭コスト
※ 金銭コストに関しては、本記事では省略します。
1. エンジニアリソース
エンジニアリソースは、E2Eテストを継続的に運用するために、密接に関わってきます。サービスを運用していく中で、リファクタリングや機能追加などが起きると、E2Eテストが壊れる場合があり、メンテナンスをしていく必要があります。そのため、E2Eテストの導入時期には、単にテストシナリオを追加していくことを考えるのではなく、今後のメンテナンスコストや追加するテストシナリオについても考える必要があります。そのため、エンジニアリソースはE2Eテストを続けていくために必要だと考えます。
2. テストの安定性
E2Eテストにおいて、前回成功していたテストシナリオが今回は失敗するという事象が多々あります。これの原因の1つとして挙げられるのは、テストが想定していたUI要素を検知できなかったという点です。またテストに安定性がないと、メンテナンスコストも多くかかり、E2Eテストに多く時間を取られてしまう可能性があります。そのため、主にUI検知を安定しているツール選択をしたいと考えました。
弊チームは、E2Eテストに多くの工数を割くことができない状況であることから、コードを記述しないGUIベースのツールを検討することにしました。
4. AutifyとMagicPod検証
今回はAutifyとMagicPodを検証しました。どちらもGUIベースでテストシナリオを作ることができる便利なツールです。
先ほど紹介した選定基準を元に、お話しさせていただきます。
検証項目の詳細内容
エンジニアリソース
1. シナリオ作成時間
2. シナリオ作成の難易度
テストの安定性
1. シナリオ作成の柔軟性
2. シナリオ作成準備の必要性
シナリオ作成時間(エンジニアリソース)
E2Eテストは、システム全体をカバーするために多くのシナリオを作成する必要があります。したがって、シナリオ作成時間は、テストツールの選択において重要な基準です。ツールの効率性は、テストシナリオの作成、実行、保守にかかる時間を大幅に短縮できます。したがって、シナリオ作成時間を短縮できるツールを選択することは、全体的なテスト時間を最小限に抑えるために重要です。
シナリオ作成の難易度(エンジニアリソース)
ツールの使いやすさは、シナリオ作成の難易度に直結します。使いやすいツールは、テストシナリオの作成を容易にし、初期の段階からシナリオを多く増やすことが可能になります。またテストシナリオの作成が容易な場合、メンテナンスコストも減少すると考えます。したがって、直感的で使いやすいツールを選択することは、E2Eテストの効率と品質を向上させるために重要です。
シナリオ作成の柔軟性(テストの安定性)
テストツールに柔軟性があることで、テストシナリオの幅が広がります。条件分岐を使えることやアサーションの安定性は、E2Eテストにおいては、テストの効率と安定性に関わってきます。そのため、柔軟にテストを作ることができるツールを選定することが重要です。
シナリオ作成準備の必要性(テストの安定性)
テスト環境の設定、データの準備など、シナリオ作成以外の準備作業が多いと、テストの効率が低下します。したがって、準備作業が少ないツールを選択することで、全体的なテスト時間を短縮できます。
上記の検証項目について、AutifyとMagicPod検証比較は、下記の表と説明で紹介します。
Autify
テストシナリオの作成時間や難易度については、UI要素を単純にタップするだけでテストが作成できるため、手軽かつ迅速に多数のテストシナリオを作成できるという点が、導入直後から多くのテストシナリオを追加できるという大きなメリットです。また、このシステムは非エンジニアでも容易にテストシナリオを作成できるという利点があります。
テストシナリオ作成の柔軟性や準備の必要性については、Autifyでは具体的な条件分岐の作成が難しかったり、動的な要素が含まれている場合にはテストが不安定になる傾向があると感じました。これは、要素を検知する内部機構を修正できないという制約からくるもので、その結果、シナリオ作成の柔軟性はやや低めと言えるかもしれません。この問題を解決するためには、テスト用のデータをサーバー側で準備してもらうか、あるいはクライアント側でテスト用のデータとしてFakeやMockを用意する必要があると考えられます。
MagicPod
テストシナリオの作成時間や難易度については、UI要素をタップし、簡易的な設定を行うだけでテストを作成できる点は非常に便利です。しかし、UI要素に対して高度な設定やアクションを要求すると、その作成時間は長くなり、難易度もやや高くなります。この点をAutifyと比較すると、シナリオの作成時間は長くなる傾向にあります。非エンジニアでも適切なオンボーディングが行えれば、テストシナリオの作成が可能であるという印象を持ちました。
シナリオ作成の柔軟性や準備の必要性については、MagicPodは高度な条件分岐の作成が可能であり、また要素を検知する内部機構（ロケータ）の修正が可能な点が、テストの安定性を高めるための有効な手段となり得ます。MagicPodでは、SemanticsNodeという単位でWidgetを扱うことができ、適切なコードを記述することで、要素を安定的に読み取ることが可能です。そのため、テスト用のデータをサーバー側に準備してもらう必要はありません。ただし、SemanticsNodeを設定しない場合、UIの要素が動的に変化する場合には安定性を保つことが難しい傾向があります。
比較検証のまとめ
Autifyの特長は、容易にテストを作成できることにあります。これにより、ある程度の品質を持つテストの運用が可能となります。また、シナリオの作成時間が短いため、多数のシナリオを追加するのに適しています。 一方、MagicPodは工数が少し掛かるものの、UI要素を安定して検知できるため、コア機能に焦点を当てたE2Eテストの構築に適しています。 したがって、Autifyは多数のシナリオを迅速に作成するニーズに対応し、MagicPodはコア機能の安定性を確保するテストに優れていると感じました。
5. E2Eテストを運用開始するために
弊チームでは、E2Eテストを運用するための準備として様々な取り組みをしていたので、ご紹介させていただきます。
大きく3項目あり、1つずつ紹介させてもらいます。
1. テストシナリオ優先付け
最初にテストシナリオの優先付けについてです。E2Eテストは、システム全体をカバーするために多くのシナリオを作成する必要があるため、「どのシナリオを優先的に追加するかどうか」という観点が大事になっていきます。その際にTest Case Prioritizationという考え方をもとに優先度付けを行いました。特にAmebaマンガでは、「探す」、「買う」、「読む」という3つの観点が事業的にも大切にしている体験なので、この3つの観点を軸にテストシナリオの優先付けをしました。またこれ以外にも、テストシナリオの作成難易度や事業インパクトを考慮して優先度付けを行いました。
2. E2Eテスト運用計画
次にE2Eテスト運用計画についてです。弊チームでは、E2Eテストの知見とエンジニアリソースが少ないという理由から、初期段階から多くのシナリオを追加するのは、手戻りの原因になると考えました。そのため、E2Eテスト導入初期段階では、1つのコア機能に絞り、実際に運用してみた上で、今後のE2Eテストの運用を改善していくという方針になりました。
また初期段階の運用では、「メンテナンスコスト」、「手動テストのコストの削減」、「エラー検知」という3点に焦点に当て、チームにE2Eテストが必要であるか、また導入することでメリットがあるかを検証しながら運用をする方針になりました。
「メンテナンスコスト」
テストケースを定期実行し、新たな機能やリファクタリング等で発生するメンテナンスコストを考慮する必要があります。具体的には、テストケースの作成や更新に必要なエンジニアの時間、テスト環境のセットアップが必要となります。仮にメンテナンスコストが肥大化すると、開発に影響が出るので、テストの運用方法を見直す必要があります。
「手動テストのコストの削減」
E2Eテストを実施することで、手動テストの手間を削減できるかどうかを検証する必要があります。具体的には、E2Eテストによって手動でのテストやバグのチェックが減少し、品質が維持されているかを検証する必要があります。E2Eテストを導入後、実際に手動テストの項目をE2Eテストで網羅できているか、またE2Eテストは手動テストに変わる一定の信頼があるテストであるかを判断する必要があります。そのため、テストシナリオが作成されてから、期間を空け、運用し、手動テストを行うタイミングでE2Eテストも実行することでテストの信頼度を測ることができると考えました。
「エラー検知」
特に機能追加やリファクタリング、人為的ミスから生じるデグレやエラーを一定期間で検知することができるかを検証します。そのために定期的に実行するE2Eテストにおいて、失敗した際の原因をメモをすることで、一定期間のデグレやエラーを検知して、E2Eテストが有用性があるものかどうかを判断します。
E2Eテストの運用については、まずは小規模な範囲から始めて、その結果を基にスケールアップすることを検討しました。また、E2Eテストの結果をチーム全体で共有し、改善点を見つけ出すことで、運用を継続的に改善していく方針を立てました。
3. チーム内でのオンボーディング・ハンズオンの開催
E2Eテストを継続して運用していくためには、チームの協力が必要となります。そのため、チーム内でオンボーディング・ハンズオンを実施しました。
内容
E2Eテストの重要性や今後の戦略を共有し、実際にAutifyとMagicPodを触ってもらうために課題を用意し、時間内に終わるかどうかを検証を兼ねて行いました。
オンボーディング・ハンズオンのメリット
- チームメンバーがE2Eテストを運用するために必要な知識を得ることができる
- チームメンバーで運用について議論することができる
実施した結果、本来は多くのシナリオを初期段階から網羅する予定でしたが、コア機能に絞ったE2Eテスト運用に切り替えることができ、チームと話し合うことでE2Eテスト戦略が改善されました。
最後に
いかがだったでしょうか？E2Eテストは品質の向上やコスト削減にも繋がる良い取り組みである反面、運用していくのには苦労します。そのため本当にE2Eテストを導入していいのかをチームでよく話し合い、最善の選択をすることがプロジェクトの成功につながると思います。
この記事が誰かのためになれば幸いです。
ここまで読んでいただき、ありがとうございました。 今後もE2EテストやFlutterについて発信予定です。