こんにちは！現場では、主にAndroidの開発をしている今井です！
今回は、弊社で実践しているモバイルアプリのテスト手法に関してご紹介をします。

テストをする上でもっとも重要なこと

以前の記事で、 テストにおいて一番重要な部分は、要求仕様書、設計書から試験項目を起こして実施と書きました。

なぜこのフェーズが一番重要かというと、アプリが仕様通り動くことを担保するのは試験項目書だからです。

試験を行う前にはコードレビューといった工程を通過することで、アプリの不具合などを減らしていきますが、 試験項目書はアプリをリリースする前の最後の砦になります。

そこで試験項目書にはバグの検出率が求められますが、どういったことに気をつければいいのでしょうか？

モバイルアプリのテストで気をつけるべき観点

アプリによって発生するバグも様々ですが、モバイルアプリには良く起きるバグにいくつかパターンがあります。

そういったパターンを試験項目が押さえておくことでバグの検出率が高まると思います。

ここでいくつか紹介させていただきます。

画面遷移のパターンは網羅できてるか？

状態が復元されるかどうかというは、例えばスクロールできる画面の場合、 画面Aをスクロール -> 画面Bに遷移 -> 画面Aに戻るという操作をしたときに、 画面Aに戻ってきたときに元のスクロール位置に戻っているといったことです。

また、表示していたデータが元のまま表示されることも重要です。

アプリによっては、画面が表示されるたびにデータの更新が必要なものもあると思いますが、 その場合を除き、気をつけておくべきです。

通信エラーのパターンは網羅できてるか？

通信エラー時の挙動にも気をつけなくてはなりません。 通信エラーと一口に言っても、ネットワークが悪い場合、 サーバーが悪い場合などいくつかパターンがあります。

違うエラーにはそれぞれにあったメッセージや、エラー時の挙動を起こす必要があります。

特にステータスコードごとの挙動には注意を払う必要があります。

こういった場合を細かくチェックすることもバグを減らす重要な観点になります。

データがある場合、ない場合の表示

意外に見落としがちなことですが、表示すべきデータがない場合(エンプティステート)の表示を確認する必要があります。

表示すべきものがある前提で画面は作られがちです。

そのため、エンプティステートの場合、表示しなくてはいけないメッセージが抜け落ちていたりする場合があります。

例えば、ユーザーを表示する画面でデータが一件もない場合、「登録されているユーザーは0件です。」

といった具合です。

サポート対象の端末にインストールできるか

この問題はAndroidでよく発生します。

Androidは非常に多くの端末で採用されているため、アプリが対象にする端末にインストールできること、 動作することを担保する必要があります。

しかし、インストール対象の端末を全て手に入れるのは困難なため、 ストアに公開した後にインストールできない端末が発覚する場合があります。

Androidであれば、manifestファイルの定義を確認するなど、そういった観点も必要になります。

まとめ

いかがでしたでしょうか。

今回は、試験項目を作成する上で気をつけるべき観点をいくつか紹介させていただきました。

それぞれの観点は試験を作成する上でも重要ですが、仕様を定める段階でも気をつけておくといいです。

仕様が明確であればあるほど、「この時はこうなる」ということがはっきりするため試験項目の精度も高まります。

試験の精度を高め、品質の高いアプリを作っていきましょう。