http://techblog.isoroot.jp/2016-10-20T12:00:00+09:002016-10-20T12:00:00+09:00imai.ktag:techblog.isoroot.jp,2016-10-20:mobile_test_items.html

<p>こんにちは！現場では、主にAndroidの開発をしている今井です！</br> 今回は、弊社で実践しているモバイルアプリのテスト手法に関してご紹介をします。</p> <h1>テストをする上でもっとも重要なこと</h1> <p>以前の記事で、 テストにおいて一番重要な部分は、<strong>要求仕様書、設計書から試験項目を起こして実施</strong>と書きました。 </br> </br> なぜこのフェーズが一番重要かというと、<strong>アプリが仕様通り動くことを担保するのは試験項目書</strong>だからです。 </br> </br></p> <p>試験を行う前にはコードレビューといった工程を通過することで、アプリの不具合などを減らしていきますが、 試験項目書はアプリをリリースする前の最後の砦になります。 </br> </br> そこで試験項目書にはバグの検出率が求められますが、どういったことに気をつければいいのでしょうか？ </br></p> <h1>モバイルアプリのテストで気をつけるべき観点</h1> <p>アプリによって発生するバグも様々ですが、モバイルアプリには良く起きるバグにいくつかパターンがあります。 </br> </br> そういったパターンを試験項目が押さえておくことでバグの検出率が高まると思います。 </br> </br> ここでいくつか紹介させていただきます。 </br></p> <h3>画面遷移のパターンは網羅できてるか？</h3> <p>状態が復元されるかどうかというは、例えばスクロールできる画面の場合、 画面Aをスクロール -&gt; 画面Bに遷移 -&gt; 画面Aに戻るという操作をしたときに、 画面Aに戻ってきたときに元のスクロール位置に戻っているといったことです。 </br> </br> また、表示していたデータが元のまま表示されることも重要です。 </br> </br> アプリによっては、画面が表示されるたびにデータの更新が必要なものもあると思いますが、 その場合を除き、気をつけておくべきです。 </br></p> <p><img alt="transition.png" src="/images/transition.png" /></p> <h3>通信エラーのパターンは網羅できてるか？</h3> <p>通信エラー時の挙動にも気をつけなくてはなりません。 通信エラーと一口に言っても、ネットワークが悪い場合、 サーバーが悪い場合などいくつかパターンがあります。 </br> </br> 違うエラーにはそれぞれにあったメッセージや、エラー時の挙動を起こす必要があります。 </br> </br> 特に<strong>ステータスコードごとの挙動</strong>には注意を払う必要があります。 </br> </br> こういった場合を細かくチェックすることもバグを減らす重要な観点になります。 </br></p> <h3>データがある場合、ない場合の表示</h3> <p>意外に見落としがちなことですが、表示すべきデータがない場合(エンプティステート)の表示を確認する必要があります。 </br> </br> 表示すべきものがある前提で画面は作られがちです。 </br> </br> そのため、エンプティステートの場合、表示しなくてはいけないメッセージが抜け落ちていたりする場合があります。 </br> </br> 例えば、ユーザーを表示する画面でデータが一件もない場合、「登録されているユーザーは0件です。」 </br> </br></p> <p>といった具合です。 </br></p> <h3>サポート対象の端末にインストールできるか</h3> <p>この問題はAndroidでよく発生します。 </br> </br> Androidは非常に多くの端末で採用されているため、アプリが対象にする端末にインストールできること、 動作することを担保する必要があります。 </br> </br> しかし、インストール対象の端末を全て手に入れるのは困難なため、 ストアに公開した後にインストールできない端末が発覚する場合があります。 </br> </br> Androidであれば、manifestファイルの定義を確認するなど、そういった観点も必要になります。 </br></p> <h1>まとめ</h1> <p>いかがでしたでしょうか。 </br> </br> 今回は、試験項目を作成する上で気をつけるべき観点をいくつか紹介させていただきました。 </br> </br> それぞれの観点は試験を作成する上でも重要ですが、仕様を定める段階でも気をつけておくといいです。 </br> </br> 仕様が明確であればあるほど、「この時はこうなる」ということがはっきりするため試験項目の精度も高まります。 </br> </br> 試験の精度を高め、品質の高いアプリを作っていきましょう。</p>

2016-10-10T12:00:00+09:00imai.ktag:techblog.isoroot.jp,2016-10-10:mobile_test_flow.html

<p>こんにちは！現場では、主にAndroidの開発をしている今井です！</br> 今回は、弊社で実践しているモバイルアプリの開発フローに関してご紹介をします。</p> <p>日々進化するモバイル端末に対して、モバイルアプリ開発で以下のような悩みを抱えてませんか？</p> <ul> <li>iOS/AndroidなどOS、端末が複数ある</li> <li>OSも、開発するアプリもアップデートが頻繁でテストが大変</li> <li>アプリの設計が悪く、バグがたくさん！</li> <li>などなど</li> </ul> <p></br> こういった課題に関して、弊社が<strong>モバイルアプリ開発</strong>で実践しているノウハウを数回に分けてご紹介していきます。 </br></p> <h1>開発のフローはどんな形？</h1> <p>全体的なフローは、 </br></p> <ol> <li>コードを書く・レビューするを繰り返す（開発）</li> <li>テスト用のバイナリをデプロイする</li> <li>試験項目を作成し、テストを行う</li> </ol> <p>です。 </br> </br></p> <p>上記のフローのうち、テストにおいて一番重要な部分は、<strong>要求仕様書、設計書から試験項目を起こして実施</strong>です。 </br> </br> 何とも素朴かもしれませんが、<strong>これが基本</strong>なのです。 </br> </br> プロジェクトによっては自動テストを導入したりしますが、試験項目書の作成は必須ですね。</p> <h1>バージョン管理はGitを使うこと！</h1> <p><img src="/images/gitlab.png" width="50%"></p> <p>開発中のバージョン管理システムは主に<a href="https://about.gitlab.com/">GitLab</a>を使用しています。</br> Gitを使った開発では、どんな風にブランチを運用するかが重要です。 </br> </br> 弊社では、GitLabとGit Flow(<a href="http://nvie.com/posts/a-successful-git-branching-model/">a successgull git branching model</a>)を部分的に取り入れたフローで運用しています。 </br></p> <h3>コードレビュー</h3> <p>実際の開発では、GitLabのMerge Requestという仕組みにより開発者同士がコードレビューを行っています。 </br> </br> 開発時は専用のブランチを作成し、開発が完了したら、本流と合流してもらうように、Merge Requestを出します。 </br> </br> コードレビューの結果、問題なければ本流にMergeされるのですが、ここで、必ず意識していることがあります。それは、 </br> </br></p> <p><strong>テストコードが書かれていること</strong>です。 </br></p> <h3>テストコードを作ること！</h3> <p>「テストがないコードは古い」とまで言われる昨今、 テストコードは可能な限り記述するようにしています。 </br> </br> テストコードがあることによって、機能・メソッド一つ一つの信頼度が上がり、 人力の試験だけでは補えない部分までカバーすることができます。 </br> </br> テストコードを書くことは、開発者のスキル向上にも直接つながりますしね！</p> <p>また、品質の担保は最終的には人力頼みとなりますが、 開発中からできる限り見落としや考慮漏れを排除するために、 テストコードを書かないとMargeしないなど、 ルールを設けるようにして運用しています。 </br></p> <h1>テストアプリのデプロイはDeployGateを使うべし！</h1> <p></br> <strong>まだケーブルを使って転送してませんか？</strong> </br></p> <p>開発が終わり、テスト用のバイナリを端末にデプロイするのですが、 弊社では、バイナリをインストールする手段として、 </br> </br> <a href="https://deploygate.com">DeployGate</a>を使用しています。 </br> </br> DeployGateは、アプリインストールを効率化するツールで、 こちらも開発環境に依存したバグ等を防ぐとともに、 実機にインストールするためのオーバーヘッドを下げることで、 試験の効率化を図っています。 </br> </br></p> <p>また、テスト用のバイナリ作成は必ずCIツールで生成されたものを用いるようにしています。 </br> </br> これは、開発環境に依存した不具合などを防止するために有効な手段となっています。</p> <h1>試験項目を作成する際に注意すべき点を洗い出すべし！</h1> <p>さて、テスト対象のアプリが用意され、試験できる準備が整いましたが、 肝心の試験項目はどういったことに気をつけて作成するべきなのでしょうか。 </br> </br></p> <p>アプリの世界観や要求にもよりますが、以下の点に気をつけると、不具合が発生しづらくなるかと思います。</p> <ol> <li>画面が再表示されたとき、状態が復元されるかどうか</li> <li>通信エラー時の挙動に気をつける</li> <li>データがない時(エンプティステート)の表示は問題ないか</li> <li>サポート対象の端末にインストールできるかどうか</li> </ol> <p>モバイルアプリのテストは、アプリの状態だけでなく、端末の状態や外的要因（ネットワーク等）にも気を配る必要があります。 </br> </br> また、OSバージョンの違いなどにも注意しないといけないため、できるだけモバイルアプリに最適化されたテスト項目が準備されなくてはいけません。 </br> </br> テスト観点に関して、次回以降にさらに詳しく紹介させていこうと思います。</p> <h1>まとめ</h1> <p>いかがでしたでしょうか。 </br> </br></p> <p>モバイルアプリ開発において、様々なOS・端末への対応は必須事項ですが、 だからこそバグの混入を防ぐことは困難です。 </br> </br></p> <p>テストコードの準備や、試験項目の精度を高めるなど、 何重にも保険をかけることで品質の高いアプリ開発を行っていきたいものですね。</p>