メルカリ ハロにおけるFlutterアプリのQA戦略:クロスプラットフォーム開発のメリットと注意点

こんにちは。メルカリWorkチームQA Engineerの@umです。
この記事は、連載:メルカリ ハロ 開発の裏側 – Flutterと支える技術 –の5回目と、
Mercari Advent Calendar 2024 の15日目の記事です。

今回は私達が開発している「メルカリ ハロ」のモバイルアプリのQAに焦点を当てて紹介します。

概要

メルカリ ハロのモバイルアプリは、クロスプラットフォームフレームワークであるFlutterを採用しています。Flutterによる開発は、単一のコードベースでiOSとAndroid両方のアプリを構築できるため、開発効率の向上に大きく貢献しています。QA活動においても、テスト効率の向上に貢献できるのですが、その特性を理解した上で適切なテスト計画を考える必要があります。この記事では、メルカリ ハロにおけるFlutterアプリQAのメリット・注意点、そして私たちが実践しているテストの進め方について解説します。

前提

モバイルアプリ開発には、「ネイティブアプリ開発」と「クロスプラットフォーム開発」という大きく二つのアプローチがあります。Flutterは後者のクロスプラットフォーム開発を可能にするフレームワークです。
ネイティブアプリ開発とは、iOSならSwift、AndroidならKotlinといった、プラットフォーム専用の言語とSDKを用いて開発する手法です。
対するクロスプラットフォーム開発とは、単一のコードベースで複数のプラットフォーム(メルカリ ハロではiOSとAndroid)に対応するアプリを開発する手法です。
この特徴はネイティブアプリの開発者だけでなく、QAエンジニアにとってもテスト効率の向上に大きく貢献します。具体例を以下に示します。

Flutterを用いたクロスプラットフォーム開発におけるQAのメリット

同時テストによる効率化と品質向上

iOSとAndroidアプリの実装が同時完了するため、両OSのビルドを並べての比較検証が可能になります。これにより、一つの観点で両OSを確認できるだけでなく、OS間のUIの差異や、それぞれ別でテストした場合に見逃しがちな細かな不具合の発見につながります。

また、私たちはスクラム開発の手法を採用しており、QAエンジニアもスクラムチームの一員として参加しています。スクラム開発を行う上で、1つのユーザーストーリーを1枚のストーリーチケットとして扱っており、開発はユーザーストーリー単位で実装されるため、テスト実行もユーザーストーリー単位で実行します。
そのプロセスにおいても、両OSのテストをチケットを分けることなく1枚のストーリーチケットでまとめて実施できるため、管理工数の削減にも貢献しています。

開発者とのコミュニケーションコスト削減

QAを行う上で開発者とのコミュニケーションは必要不可欠です。具体的には、スケジュールの調整から始まり、仕様の認識合わせ、開発視点で考慮が必要な観点、Acceptance Criteria(以下ACと記載します)の過不足のチェック、リリース手順の確認など多種多様なコミュニケーションが発生します。

機能をより早く、より安全にリリースするためには、こういったコミュニケーションの質や量を担保することが必要ですが、開発担当者が増えれば増えるほどコミュニケーションの難易度とコストは上がります。一般的にネイティブアプリ開発の場合はOSごとに開発者が分かれていることが多いため、例えばMTGの時間を合わせることが難しくやむをえず情報伝達に時間差が生じてしまったり、複数の担当者間での認識の齟齬が生まれたりすることなどが起こり得るかと思います。一方でFlutterのアプリケーション開発においては両方のOSを同一の開発者が担当するため、やり取りする担当者の数は最小限ですみます。これは単純ではあるものの大きな違いであり、これによりコミュニケーションの難易度とコストが抑えられるように感じます。

テストケース量の削減

テストケース数を少なくするためのアイディアとして、Flutterの単一コードベースの特徴を活用することができます。

具体的にはバックエンドAPI呼び出し部分やレスポンス表示部分などは片方のOSで正しく動作することを確認できれば、もう片方のOSでのテストを省略できる場合があります。
事前に開発者と実装内容や影響範囲を確認した上で、このような戦略的なテストケース削減を行うことで、リリースまでのリードタイム短縮につなげることができます。

Flutterを用いたクロスプラットフォーム開発におけるQAの注意点

メリットが多い一方で、Flutter特有の注意点も存在します。

両OSの不具合影響

Flutterが単一コードベースであるがゆえに、実装上の不具合が両OSに同時に影響を及ぼす可能性があります。このリスクを低減させるために適切な品質保証活動を行う必要があります。
具体的な活動については、QA Engineering ManagerのrinaがACについて記述した本連載1回目の記事をご参照いただければと思います。

OS固有の実装への対応

Flutterは単一コードベースを原則としますが、OSに依存した機能など特定の処理に関してはOSごとに異なる実装を行う必要があります。
メルカリ ハロでは、一例ですが以下のような機能でOSを意識した実装をしています。
・応募したおしごとの日程をカレンダーアプリに登録する機能
・おしごとの労働条件通知書ファイルを端末にダウンロードする機能

QAエンジニアは、OSごとの実装が入っているかどうかについて開発者とコミュニケーションをとり、適切なテスト設計をしたり、テスト実行を行うことが重要です。

まとめ

Flutterはクロスプラットフォーム開発のメリットを享受できる一方、QAにおいてはその特性を理解した上で適切なアプローチを取ることが重要です。メルカリ ハロでは、今回ご紹介したメリット・注意点を踏まえ、効率的かつ効果的なQA活動を実践することで、あんしん・あんぜんなアプリを提供できるよう努めています。
この記事の内容が、みなさまのプロジェクトや技術的探求に貢献できたなら幸いです。引き続き「メルカリ ハロ 開発の裏側 – Flutterと支える技術 –」シリーズを通じて、私たちの技術的知見や経験を共有していきますので、どうぞご期待ください。また、Mercari Advent Calendar 2024の他の記事もぜひチェックしてみてください。それでは、次回の記事でお会いしましょう!

次回の記事は @howieさんです。引き続きお楽しみください。

  • X
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加