モバイルアプリのリリースサイクル毎で行っているテストの流れ

mobile software_test

こんにちは。@Kazu_cocoaです。最近、週末によく寒波が来ますね。布団から抜け出せなくなると評判の毛布を買ったのですが、そこから抜け出せなくなりそうです。

これはソフトウェアテストあどべんとかれんだー2014の13日目の記事です。

前日は id:ishikawa-tatsuya さんのFriendly - Windowsアプリのシステムテスト自動化でした。Friendly自体は聞いたことがあったのですが、Windows環境でテストすること自体が無かったので、どういうものか大変参考になりました。

最近、アプリのローカライゼーションが面白いなと感じました。なので、最後にちょこっと、ローカライゼーションの話も書いています。

ネイティブモバイルアプリのテスト？

多くの開発の現場では、ネイティブのモバイルアプリに対するテストって、どういうことをされているのでしょうか。どのような計画を持って、設計して、用意、実施まで行っているのでしょうか。

開発からリリースまでどのような流れに沿ってテストを実施しているかを言及しているところは少ないように思えます。多くは開発者がリリース前に自分たちで触って確認するで終わると聞きます。また、テスト会社や社内の第三者チームに実施を依頼する、ということも聞きます。

以下では、私が実際におこなっているテストの話を主に、どのような形でテスト全体を進めているかを載せてみます。(xxxLevelという表現は、More Agile Testingで使われているテストレベルの用語を持ってきています。)

ツールの話までは言及してないです。テストの呼び名とタイプの区分はちゃんと考えられていないところもあるのですが、目的でざっと把握していただけると助かります...

対象

ここで書いているテストは以下の環境で主に実施していることを書いています。

  • アプリ利用者数
  • リリースサイクル
    • 2週間前後
    • 少ない時で、数千行程度の修正が含まれる
  • クライアントアプリの話が中心

リリースサイクルの期間で実施しているテスト

Review(Task / Story Level)

  • 開発中に行うレビュー
  • GitHubのPR上で主に実施されるようなレビューをさしてます
  • 主には実装に詳しい開発者どうしで行いますが、内容に応じてテストエンジニアも参加します

Developer testing(Task / Story Level)

  • 開発者が実装ロジックを確認するためのテスト
    • xUnit系が多い
  • 主に、MVCでいうとモデル要素に対するテストが中心
  • 自動化されたテスト
Mobile App

Hermetic (GUI) Testing(Story / Feature Level)

  • モックサーバ(フェイクサーバ)を立てて、以下のように閉じた環境で行うテスト
  • UIの崩れであったり、表示文字数の同値/境界値でのレイアウト、nullチェックなどの基本的なHTTPの応答に対するアプリの動作を見ます
  • まだ手動が主。一部自動化され始めた。
Mobile App <=> Mock Server

Feature Testing(Story / Feature Level)

  • リリースサイクル内で開発した機能とそれに付随する周辺機能に焦点をあてて実施するテスト
  • 手動テスト

E2E Testing( Production Release Level)

  • 実際に稼働するサーバ含めた環境で行うテスト
  • 実データ、実ユーザを使い、一通りの画面遷移や画面操作を実施
    • シナリオベースで、必ず実施するものなどを区分し、それらを実施
  • サポートOSや端末を組み合わせて選んだ端末でテストを実施
  • 多くが自動化されている。手動で自動化されていないところをカバー。
  • 接続は、Staging/Productionともに。
Mobile App <=> Staging/Production Server

Exploratory Testing (Production Release / System Level)

  • 以下のような雛形みたく、特定の不具合/改善点を見つけるために一定の時間を決めて行う形式で行っているテスト(time box management)
Explore …
With …
To discover …
  • ユーザビリティを考慮して修正が必要そうだと判断されるような不具合もこちらで検出してます
  • 負荷テストのようなこともこちらの区分で今は実施しています
  • 手動テスト
Mobile App <=> Staging/Production Server

テストの実施者

基本的に社内。理由は、ドメイン知識がある程度なければ手順通りにテストを実施するしかなくなること。単純に手順をたどるだけのシナリオテストであれば自動化され始めているので人手で行う必要性が小さい。

機種依存が強い機能だと確定している機能に関しては、他機種試験のために外部にお願いすることもありますが、最近は機種依存もそこまで警戒するものではなくなってきました。

以上のような流れを経て、アプリを毎回リリースしています。最近この流れまで落ち着いたのですが、Hermetic Testingなんかは比較的最近実施するようになりました。もう少し自動化を進めて効率化を測りたいなと考えています。

自動化ピラミッドにおけるExploratory Testing

蛇足ですが、Exploratory Tesitng含めた自動化ピラミッドで、以下のように定義されているものがあります。そのExploratory Testingの位置づけが個人的にはもっと重要な気がしてます。

http://watirmelon.com/2011/06/10/yet-another-software-testing-pyramid/

モバイルアプリはユーザに最も近い端末で動作するアプリになるので、もっと探索的に色々テストすることの重要性が高いと思うのですよね。そこでダメだと、実装を変更するなんてことが日常茶飯事に発生することなので。

リリース後の監視はしっかりやりましょう

少しテスト自体の話からそれますが、リリース後の監視の話です。テストではリスクの高さによって対応の優先度を判断しています。その優先度判断において、世に出ているアプリの状態を知り、反映できるようにすることは大事なので少し。

ユーザ環境でどれだけクラッシュしたか、クラッシュしないが修正が必要な不具合があるかなど、検出、計測可能な状態にしておくことは非常に重要です。また、HTTPのリクエスト/レスポンスの計測はサーバサイドではありますが同様に大事です。

クラッシュなんかは目に見えやすく、ユーザの体験を著しく損ないます。

モバイルアプリをテストする場合に求められる知見

実際にモバイルアプリをテストして、ここらへんの知見が必要だと感じたものを載せてみます。

番外: ローカライゼーション

ローカライゼーションって、どんなことをすると思いますか？私も翻訳すれば良いと思っていた時期がありました。Localizationとあるように、その地域に対してカスタマイズすることが必要になります。

例えば、サウジアラビア周辺では、文字を右から左に読むので、基本的に左右逆でアニメーションをつくる必要があります。Google、Appleなど見ているとOSレベルでそこらへんの取り組みが考慮されていることがわかります。 また、Facebookの記事How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networksで書かれているように、20種類のAPKを組み合わせて、特定の地域に必要なアプリを構築するとか、そのくらいの取り組みまでする必要も出てきそう。APKのつながりもあるので、組み合わせによるテストが大変になることはわかりますが、ローカライゼーションとはそういうところまで行き届いたものをさすのだなと感じました。

面白そうですね。

次回

次は id:kyon_mm さんによる「負荷テストについて」とのことです。サーバサイドの話になるのでしょうか。楽しみですね。