こんにちは、QAエンジニアのEnnです。
今年に入ってからReact Nativeで開発したアプリのテストに携わる機会がいくつかありましたが、10月から本格的にアジャイル開発でReact NativeアプリのQAを担当することになりました。チームのスプリントは2.5日で回しており、基本的には1スプリント内で開発からQAまで完結し、長くても2スプリントで開発からQAを完了するようにしています。何回かリリースサイクルを経験する中で、これまでのモバイルアプリのQA経験とは異なる点を感じることがありました。
今所属しているチームで新しい機能については手動テストで対応し、リリース後にはMagicPodを使ってE2Eテストを作成しています。今回は、React Nativeアプリの手動テストを通じて感じたことや、得た経験をシェアしたいと思います。
QA視点で感じたReact Nativeの魅力
以下は、リリースサイクルを何回か体験した後に、QAメンバーとして感じたReact Nativeアプリの魅力的なポイントです。
一貫性のあるユーザー体験
React Nativeを使用すると、iOSとAndroidの両方で同じコードベースを共有できるため、ユーザー体験を一貫して保つことができます。両OSの挙動や体験には特に差異がなく、実装の制限によりどちらに合わせるかという議論がありませんでした。
また、不具合が発生する際、ほとんどの観点では両OSで同じ事象が発生するため、バグの起票は一度で済み、片方のOSでの再現確認も同じ手順で行えるため、あまり時間がかかりません。
コストと時間の削減
React Nativeでは、開発者が一度に両OS用のコードを書けるため、開発時間が短縮されます。これにより、AndroidとiOSのビルドを同時に出すことができ、QA作業も両OSを同時に開始できます。
私自身、テストではAndroidとiOSを並行して比較しながら進めることが多いため、両OSのビルドが同時に準備されるのは非常に助かります。片方のビルドを待つ必要がなく、重複作業が減ることでテストサイクルがスムーズに進みます。
QA視点でのテストアプローチ
React Nativeの特性を活用して以下のアプローチをしました。
同じコードでの挙動確認
React Nativeでは、iOSとAndroidの両方で同じコードベースを使用してアプリを開発するため、テスト時に発生する不具合の多くは、両OSで同様の事象が発生することが多いです。起票したチケットの中に、OSに依存するチケットはわずかになります。
また、概ね以下のテスト観点では両OSで同じ事象が発生することが多いです。
- 画面の遷移
- API通信
- データの保存/読み込み
- リスト表示
- フォーム入力
限られた時間の中で効率的にテストを進めるために、上記の観点で片方のOSで問題が確認できた場合、まずは問題を起票して共有してから、残りのOSで同じ問題が発生するかを確認するプロセスを取りました。このアプローチにより、QA作業の時間を効率的に活用でき、開発メンバーが不具合共有を待つ時間が少し減ったと思います。
UIの一貫性のチェック
React Nativeのスタイリングは、iOSとAndroidで異なる部分があるため、UIの細かい部分で不整合が生じることがあります。今回の経験では、Androidで画像が表示されない現象が何度か発生しました。UI 観点を確認する際に、まず Android から確認し、表示されない問題が発生した際は、共有する前に必ず両OSで確認してから共有するようにしました。
ライブラリの更新確認
ライブラリの拡張や更新によって、特定のOSで問題が発生することがあります。今回の経験では特にiOSでは動作しない問題やテキストが一部しか表示されない問題がありました。ライブラリの更新や新しいライブラリを実装する際には、必ず両OSでテストを行った方が良いと感じました。
開発者とQAの連携
React Natvieの特性を活かした上で開発メンバーもいろいろな取り組みをしました。取り組みについて以下の資料が参考できます。 その中に以下2点がQAを対応する際にテストがもっと楽になり、動きやすくなりました。
デバッグを支援する仕組みづくり
デバックを支援する仕組みの中に以下2点がテストをする際によく活用してました。
アプリの画面上で分析用のログやパスを確認できること
数値を分析するために画面表示やCTAボタンの押下時にログが出力されるように実装することがあります。これまではログを確認する際にCharlesというツールを使用していましたが、端末の接続が不良になることがあり、その場合確認が難しくなることがありました。この問題を開発メンバーに伝えると、デバッグモードでログを確認する機能をONにすることで、操作しながら即時にログを確認できる機能を実装してもらいました。この機能のおかげで、ログのテスト対応時に手間が減り、確認がさらに楽になりました。
デバックモードのメニューから特定の画面に遷移できること
今担当しているサービスでは、一連の操作や特定の条件を満たすことで表示される画面があります。特定の画面のUIを確認したいだけなのに、事前準備にかなり時間がかかっていました。開発メンバーがこの問題に気づいてくれて、デバッグモードのメニューから特定の画面に直接遷移できる機能を実装してくれました。この機能を活用することで、テストが早くなり、とても助かりました。
workflow による自動化
GitHub上のWorkflowがいろいろ整備されていますが、その中でQAメンバーとして一番良かったのは、アプリのビルドをWorkflowのボタン一つで自分で作成できることです。これまでは開発メンバーに依頼して最新のビルドを作成してもらっていましたが、Workflowを使うことで自分でも最新のビルドを作成でき、依頼のやり取りが減りました。この機能はE2E自動化テストにも活用でき、とても便利でした。
終わりに
短い記事になりますが、参考になれば幸いです。リリースサイクルを早めるため、事前準備があまり必要ない手動テストに頼ってきましたが、上流工程から自動化テストを導入することで、もっとReact Nativeの良さを引き出せるのではないかと考えています。現在、社内ではアプリの自動化をインテグレーションテストから拡充していく方針を進めています。上流工程からの自動化テストとこれまでの手動テスト経験を組み合わせて、アプリのリリースサイクルをさらに迅速化できればと考えています。
Ubieではさらなる改善をすすめるため、QAエンジニアやその他職種の採用を積極的に行っております。ユビーのQAエンジニアに少しでも興味を持っていただけましたら、ぜひカジュアルにお話しましょう！
関連記事
Discussion