ネイティブアプリのQA業務の特徴

はじめに

QAグループのokapiです。

前回の記事では「QA業務の認知度向上」というタイトルで、
QAが案件に参画してどのようにQA作業を行っているかを記載しました。

今回は、私が最近ネイティブアプリの案件を多く担当していることもあり、
「ネイティブアプリのQA業務の特徴」について書きたいと思います。

ネイティブアプリのQA業務について

基本的なQAの設計では、テスト範囲（テスト対象/対象外）を明確にしたテスト観点を作成し、
その観点に基づいてテストケース（前提条件・手順・期待値）を作成していきます。
しかし、ネイティブアプリの設計では上記に加え

・iOSとAndroid
・テスト対象のOSバージョンとスマートフォン端末
・ネイティブアプリの機能

を考慮する必要があるため、機能がそれほど複雑ではないネイティブアプリでも
「テストの規模が大きくなりがちな特徴」があります。

項目	特徴
iOSとAndroid	・iOSはApple社が開発したOS ・AndroidはGoogle社が開発したOS であり、開発環境が異なるため、テストの分量も単純に倍の計算になります。
テスト対象のOSバージョンとスマートフォン端末	一般に発売されているスマートフォン端末は種類が多く、 それらすべてとOSバージョンの組み合わせを網羅したテストは現実的に不可能
ネイティブアプリの機能	携帯端末独自の機能やスペックがアプリの機能に影響するため、 それらの特性をふまえた上で、インストールされたネイティブアプリの動作を確認する必要がある ・Push通知 　ーアプリがユーザにお知らせを送る機能 ・タッチスクリーン 　ー画面上の領域をタッチすることで操作する機能 ・パーミッション 　ーアプリが端末にアクセスする時にユーザに許可・許可しないのポップアップを表示する機能

iOSとAndroid

iOSとAndroidのOSが異なるため、「テストの分量も倍」となるので、
工数を抑えたいところです。
しかし、開発チームもiOSとAndroidとBFFで分かれていることもあり、

• iOSで不具合がなくても、Androidで不具合が発生する
• Androidで不具合がなくても、iOSで不具合が発生する
• APIで不具合があり、Android, iOS両方でテストが必要となる

これらのパターンが各機能で発生する可能性があります。
そのため、iOSで確認済みだからAndroidでは省略、（あるいはその逆）というような進め方をすると
「品質に影響する不具合」が残存する恐れがあるため、どちらのOSでも基本実施する方針で進めています。

テスト対象のOSバージョンとスマートフォン端末

OSと端末の「全ての組み合わせのテストは不可能」であるため、
対象アプリの推奨環境（例：iOS15.0以上/Android9以上）を確認した上で、
各OSのシェア率を考慮して、メインで検証する「OS」を決定します。
そして、

• メインOS　　：全テスト実施
• メインOS以外：表示確認＋OS関連の不具合が発生した箇所

と割り当てます。

「端末」に関しては、端末依存の不具合は稀で、発生しても致命的な事象とはなりづらいので、
基本的に上記のOSに準拠した端末でテストを実施しています。

ただ例外もあり、
カメラ起動を伴う機能テストは、上記OSと端末の割り当てルールとは異なり、
持っている全ての種類の端末でテストを行います。
理由としては、これまでのネイティブアプリのQAで初回のテスト時に、いずれかの端末でカメラ起動時にアプリがクラッシュする、という不具合が割と高頻度で発生していたからです。

ネイティブアプリの機能

ネイティブアプリのQAでは、携帯端末の機能をふまえた上で
アプリが仕様通りに動作するかを確認する必要があります。
しかし、仕様書には「アプリの仕様」のみ記載されており、
携帯端末側の機能までは言及されていないことが多いです。
そのため、端末の機能がアプリの挙動に影響することで不具合が発生し得るため、
「端末の機能」を理解した上でテスト設計を行うと、ユーザビリティ観点の不具合を検出できます。

項目	アプリの仕様	端末の機能	ユーザビリティ観点の よくある不具合
Push通知	・Push通知の 　-タイミング 　-内容 　-タップした時の遷移先 ・アプリ内のお知らせの通知バッジの 　-表示タイミング 　-削除タイミング	・アプリアイコンの通知バッジ 　-複数溜まった時の表示 　-表示タイミング 　-削除タイミング ・状態の変化による仕様 　-ログイン/ログアウト 　-アプリフォアグラウンド/バックグラウンド/ロック画面	・複数通知受信時にアプリアイコンの数が通知数に一致しない ・アプリアイコンの通知バッジが 　-表示されない 　-表示されるタイミングが遅い ・アプリアイコンの通知バッジが 　-消えない 　-消えるタイミングが遅い ・通知対象でログイン→ログアウトの時に通知が 　-受け取れない 　-通知押下でエラーとなる ・アプリフォアグラウンドの時に通知が届かない
タッチスクリーン	ボタンやリンクをタップした時の動作	・ダブルタップ 　-タップを素早く２回行う ・フリック 　-指先で左右に弾くスワイプ ・スワイプ 　-ゆっくりと左右スライド ・ピンチイン 　-二本の指で同時に画面に触れて距離を狭めて縮小 ・ピンチアウト 　-二本の指で同時に画面に触れて距離を広めて拡大	・ダブルタップで 　-同じ画面が2重で開く 　-登録内容が2重で登録される ・フリック/スワイプ/ピンチイン/ピンチアウトの操作した時に表示崩れが発生
パーミッション	ー	・Push通知の許可・許可しない ・位置情報の許可・許可しない ・カメラの許可・許可しない	・Push通知の許可設定が設定と連動しない ・位置情報の許可やカメラを許可でクラッシュ

今後の課題

ネイティブアプリのQA業務では、
「システム要件に沿った仕様」と「アプリ特有の機能」を確認しており、
アプリ開発のQAに本格的に参画していく中で、iOSの審査が厳しいということを知りました。

例えば、

• 「非ログインでも利用できる」形でないとリジェクトされる
• GooglePlayのリンクが入っているだけでもリジェクトされる

などの内容です。

こういった知見もナレッジに加えていくことで、アドホックテストに観点として組み込んだ上で、
さらなる品質向上につなげていけると考えています。

さいごに

今回は、ネイティブアプリのQA業務の特徴について「テストの規模が大きくなりがち」と紹介しました。
しかし、ネイティブアプリでは、iOS,Android,APIと様々な観点でQAから多くの不具合が起票されるため、改修の対応を行う開発側の負担も高く、 Webアプリと比べて双方のコストが高い傾向にあり、現状では効率性があまり高くないと感じます。

直近で携わったアプリの開発言語はそれぞれAndroidはKotlin、iOSはSwiftでした。
プラットフォームごとのネイティブ開発には、細かなチューニングを行なえる個別最適化といったメリットがあります。

同一のソースコードで開発できるKotlin Multiplatform Mobile（KMM）やFlutterのようなクロスプラットフォームもありますが、端末の制御※など個別のOSに依存する部分は別に学ぶ必要があるなど、デメリットもあります。
※カメラ、GPS、センサー系等

その点、ネイティブ言語は対応するOSが直接サポートしている言語なので、端末の機能の活用性に対しては自由度が高くなります。

今後は開発エンジニアの指向やアプリの開発目的も踏まえて、最適な開発手法が取られていくと予想・期待しています。
QAエンジニアの立場からも、開発手法に合わせて柔軟にQAテストの効率を上げていけるよう精進していきたいです。