ISOROOT Tech Blog

今すぐ実践すべきモバイルアプリの注意すべきテスト観点

imai.k — Thu, 20 Oct 2016 12:00:00 +0900

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

といった具合です。

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

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

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

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

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

まとめ

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

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

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

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

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

今すぐ実践すべきモバイルアプリの開発フロー改善

imai.k — Mon, 10 Oct 2016 12:00:00 +0900

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

日々進化するモバイル端末に対して、モバイルアプリ開発で以下のような悩みを抱えてませんか？

iOS/AndroidなどOS、端末が複数ある
OSも、開発するアプリもアップデートが頻繁でテストが大変
アプリの設計が悪く、バグがたくさん！
などなど

こういった課題に関して、弊社がモバイルアプリ開発で実践しているノウハウを数回に分けてご紹介していきます。

開発のフローはどんな形？

全体的なフローは、

コードを書く・レビューするを繰り返す（開発）
テスト用のバイナリをデプロイする
試験項目を作成し、テストを行う

です。

上記のフローのうち、テストにおいて一番重要な部分は、要求仕様書、設計書から試験項目を起こして実施です。

何とも素朴かもしれませんが、これが基本なのです。

プロジェクトによっては自動テストを導入したりしますが、試験項目書の作成は必須ですね。

バージョン管理はGitを使うこと！

開発中のバージョン管理システムは主にGitLabを使用しています。
Gitを使った開発では、どんな風にブランチを運用するかが重要です。

弊社では、GitLabとGit Flow(a successgull git branching model)を部分的に取り入れたフローで運用しています。

コードレビュー

実際の開発では、GitLabのMerge Requestという仕組みにより開発者同士がコードレビューを行っています。

開発時は専用のブランチを作成し、開発が完了したら、本流と合流してもらうように、Merge Requestを出します。

コードレビューの結果、問題なければ本流にMergeされるのですが、ここで、必ず意識していることがあります。それは、

テストコードが書かれていることです。

テストコードを作ること！

「テストがないコードは古い」とまで言われる昨今、テストコードは可能な限り記述するようにしています。

テストコードがあることによって、機能・メソッド一つ一つの信頼度が上がり、人力の試験だけでは補えない部分までカバーすることができます。

テストコードを書くことは、開発者のスキル向上にも直接つながりますしね！

また、品質の担保は最終的には人力頼みとなりますが、開発中からできる限り見落としや考慮漏れを排除するために、テストコードを書かないとMargeしないなど、ルールを設けるようにして運用しています。

テストアプリのデプロイはDeployGateを使うべし！

まだケーブルを使って転送してませんか？

開発が終わり、テスト用のバイナリを端末にデプロイするのですが、弊社では、バイナリをインストールする手段として、

DeployGateを使用しています。

DeployGateは、アプリインストールを効率化するツールで、こちらも開発環境に依存したバグ等を防ぐとともに、実機にインストールするためのオーバーヘッドを下げることで、試験の効率化を図っています。

また、テスト用のバイナリ作成は必ずCIツールで生成されたものを用いるようにしています。

これは、開発環境に依存した不具合などを防止するために有効な手段となっています。

試験項目を作成する際に注意すべき点を洗い出すべし！

さて、テスト対象のアプリが用意され、試験できる準備が整いましたが、肝心の試験項目はどういったことに気をつけて作成するべきなのでしょうか。

アプリの世界観や要求にもよりますが、以下の点に気をつけると、不具合が発生しづらくなるかと思います。

画面が再表示されたとき、状態が復元されるかどうか
通信エラー時の挙動に気をつける
データがない時(エンプティステート)の表示は問題ないか
サポート対象の端末にインストールできるかどうか

モバイルアプリのテストは、アプリの状態だけでなく、端末の状態や外的要因（ネットワーク等）にも気を配る必要があります。

また、OSバージョンの違いなどにも注意しないといけないため、できるだけモバイルアプリに最適化されたテスト項目が準備されなくてはいけません。

テスト観点に関して、次回以降にさらに詳しく紹介させていこうと思います。

まとめ

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

モバイルアプリ開発において、様々なOS・端末への対応は必須事項ですが、だからこそバグの混入を防ぐことは困難です。

テストコードの準備や、試験項目の精度を高めるなど、何重にも保険をかけることで品質の高いアプリ開発を行っていきたいものですね。

ブラウザテストの便利ツール「BrowserStack」の知っておくべき5つのポイント

kurey — Mon, 26 Sep 2016 12:00:00 +0900

こんにちは、kureyです。

みなさんブラウザテストをする際の環境はどのように用意していますか？

利用するデバイス×OSのバージョン×ブラウザの数だけテストの実行環境を用意してテストする…。考えるだけでめんどくさいし、コストもかかるのが容易に想像できますね。

そんな時は世の中にあるWebサービスを使ってこの問題を解決しちゃいましょう。

今回取り上げるのはBrowserStackというWebサービスです。

このサービスを利用する事でどんな事ができるのか、そして他のサービスとどのような違いがあるのかをご紹介します。

1. BrowserStackってどんなサービス？使うと何が嬉しいの？

BrowserStackというサービスがどういうものかを一言でいうと各種OS、各種ブラウザをあなたがお使いのブラウザ上から操作をできるようにしてくれるサービスです。

このサービスの一番の魅力はブラウザテストするために必要な環境を準備する事が不要になることです。

2. どのぐらいの環境が用意されてるの？

BrowserStackにはとても豊富な環境が用意されています。（詳しくはコチラ）

Windows XPからWindows 10まで、MacはOS X Snow Leopard(v10.6)からOS X El Capitan(v10.11)までをサポートし、ブラウザはIE、Safari、Chrome、Firefox、Operaなど主要ブラウザはほぼ網羅しています。

3. ブラウザ毎の表示確認ぐらいなら他サービスで良くね？

ブラウザのスクリーンショットだけを確認したいだけであれば「modern.IE¹」や「BROWSER SHOTS」など確認したいWebページのURLを入れるだけで確認ができるWebサービスが存在します。

もちろんBrowserStackにも「Screenshots」というものがあり、他サービスと同様にWebページのURLを入力し、スクリーンショットを取りたいOSとブラウザを選択することでお手軽に表示確認をすることができます。

…だが、BrowserStackには更にLiveという機能が存在し、あなたのブラウザ上から全く別のOS、まったく別のブラウザをリアルタイムで操作することができ、より細かな動作確認ができるのです。

例えば動的なページに対して何か操作を行った結果が問題ないかを確認したい場合などに効果を発揮します。

4. もちろん自動実行も備えてます。

ScreenshotsやLiveという機能で表示確認や操作を毎回手動でテストするのはやはりコストがかかってしまいます。

そこで登場するのがBrowserStackのもう一つの機能Automateです。

これはSeleniumなどのテストコードを実行する事でBrowserStack上で用意されているブラウザのテストを自動で行うことができます。

Jenkinsと組み合わせて毎日定期実行することで継続インテグレーションを実現することができます。

また、AWS Device Farmも2015年11月にWebアプリケーションテストに対応し、同じようにテストコードからブラウザのテストを自動実行できるようになったため、スマートフォンのブラウザテストはAWS Device Farm、PCのブラウザテストはBrowserStackといった使い分けができます。

5. 有料サービスであること

最後はデメリットになります。

BrowserStackはとても魅力的なサービスではありますが、いいサービスには対価が伴います。

そうです、お金ですね。

プラン	料金
Live	$29
Automate	$59
AutomatePro	$99

※上記は１ユーザ１セッションの場合の値段のため、複数人で同時に利用する場合には更に値段が高くなります。

BrowserStackは月額プランとなっており、あまりお気軽に試してみようというには若干高い金額となっておりますが、他サービスのAWS Device Farmと比べると多少安価²な値段設定となっている。

まとめ

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

Web開発者にとってクロスブラウザの確認はほぼ必須となっており、確認するための環境作りなどで手間を割かれてしまうのはとても勿体ない事であり、その時間をもっと開発に使える事ができればより良いサービスを生み出す事ができるでしょう。

BrowserStackはそんな手間を解消してくれるとても魅力的なサービスであるため、まずはFreeTrialで試してみるのはいかがでしょうか。

modern.IEはBrowserStackを使ってスクリーンショットをとっている。 ↩
AWS Device Farmの料金設定は$0.17/分、$250/1デバイススロット(iOS/Android毎に契約可能な月額プラン) ↩

タブレットが壊れる！？アプリUIの改善でタブレットの寿命を延ばすの巻

anannori — Fri, 26 Aug 2016 13:00:00 +0900

スマートデバイスの業務アプリをやってきて遭遇したあんなことやこんなこと。

当社では、様々なお客様の業務の現場へ、モバイルデバイスを活用したアプリやシステムをご提供してきました。
その中で実際に起きた色々な事例と、その対策アプローチをご紹介します。

スワイプしすぎでタブレットの画面が削れてきた！

写真はイメージです。

画面を移動したり、アイテムを移動させたり。タッチパネル画面を指でなぞるようにして操作する、”スワイプ”。スマホやタブレットを使う人にとってはごく一般的な操作方法です。
当社のSmartGEMBA 巡回点検アプリを半年ほどご利用頂いたあるお客様から、ご相談がありました。
「見てください。タブレットの画面が、削れて穴が開きそうです」

感圧型タッチパネル x ハードタイプのタッチペン x 毎日数千回のスワイプ

このアプリのUIには左右にスワイプする操作が頻繁に登場します。でもそれだけでは画面が削れたりなんて普通はしません。
実はこのお客様、利用している端末がちょっと珍しい「感圧式」タッチパネルの業務用タブレットでした。(感圧式タッチパネルの端末は、手袋などをしていても、ぐっと画面を押すことで操作できるため、SmartGEMBAをご利用頂くような、現場の運用では利用候補に挙がります。一般的には静電方式タッチパネルですが、仕事で使う手袋では反応してくれないのです。)
さらに、ハードタイプのタッチペンとを併用して、毎日画面を左右に数千回スワイプしていることが分かりました。
これだけ酷使すれば、確かに画面が削れて来ても不思議ではありません。

ソフトウェアからの対策アプローチ。スワイプ無しで操作可能にＵＩ変更。

結果的には、アプリのUIを変更することで解決しました。スワイプ操作と同じ結果をもたらす、ボタンを新設したのです。
変更前のスワイプは、タッチしてそのまま左右に4cm程スライドさせます。変更後は画面にペン先で点で振れるだけで同じ結果を生むように変更しました。
これによってタッチペンと画面との摩擦が減り、画面破損への影響は無くなりました。

教訓

ソフト・ハード・使い方の組み合わせで、やってみて分かることがあります。
実際の利用現場でプレ運用、フィールドテストを経て、フィードバックを得ることが重要です。

Selenium(Java)でブラウザテストをするときにやっておくべき３つのこと

kurey — Mon, 15 Aug 2016 12:00:00 +0900

こんにちは、kureyです。

今回は私がSeleniumとJavaを使ってWebアプリケーションの画面テストをする際に気を付けたことを３つご紹介します。

Seleniumとは？

Seleniumとは、ブラウザのテストで用いられるフレームワークです。

ブラウザに表示されているテキストなどの要素が正しく表示されているか？
ボタンをクリックすることで遷移する先のURLが正しいか？

などのサイト上の動作を様々な言語¹で記述されたプログラムによりテストする事ができます。

これは世に出ている様々なブラウザ上で自分のサイトが正しく動作しているか、定期的にテストするためによく使われます。

1. Seleniumでテストする範囲を決める

１つ目に気を付けるべき点はSeleniumでテストする範囲を決めることです。

最初から全ての画面の全ての操作をSeleniumで自動化しようとすると、テストコードを書くコスト物凄くかかる上、メンテナンスも大変となります。

私がSeleniumでテストを行った時は各画面で必ず存在するようなヘッダーやフッターの表示、メニューなど共通の画面で利用できるもの、ブラウザリロードやブラウザバックした時の動作、それぞれが想定通りの動作となっているかという点に観点を絞り、テストの範囲を最小限にしました。

このように自動化する範囲を各画面で必ず行うような操作に限定する事でテストコードは汎用的にしやすく、プログラムに落とし込むコストは大幅に削減でき、最小限のコストで最大限のパフォーマンスを発揮する事ができます。

2. テストコードを書く上でルールを決める

２つ目はテストコードを書く上でもコーディングルールを決めることです。

複数人でテストを書く場合、ルールを決めておかなければそれぞれが好き勝手書いてしまい、せっかくテストする範囲を限定したにも関わらず煩雑なテストコードが生まれてしまいます。

煩雑なテストコードとは、FirefoxのSelenium IDEを利用して画面上の操作をキャプチャし、それをそのままテストコードとして利用する場合が該当します。

FirefoxのSelenium IDE自体は画面上の操作を記録してテストコードを生成してくれるため、テストコードを作る上ではとても早いですが、テストコードの再利用が出来ないことや、画面変更が発生した際にSelenium IDEで操作を記録してテストコードを生成する必要が出てきてしまいます。

通常のプログラム同様、ある一定のルールを用いて開発を進めないと保守性の低いアプリケーションが完成しますよね？

たかがテストコード、されどテストコード。

アプリケーションの品質を高い保つためにはテストコードもクリーンにすることをオススメします。

ページオブジェクトパターンというデザインパターン

ここでご紹介するのはページオブジェクトパターンというデザインパターンです。

ページオブジェクトパターンとは、テストコードを記述する上でWebアプリケーション上の画面１つをオブジェクトとして捉えるデザインパターンの１種です。

Seleniumの公式でも推奨されている保守性の高いテストコードの書き方となります。

以下、公式に記載されているPageObjectの原則

・The public methods represent the services that the page offers（publicメソッドは、ページが提供するサービスを表す）

・Try not to expose the the internals of the page （ページの内部を公開しないこと）

・Generally don’t make assertions （原則としてassertionを行わないこと）

・Methods return other PageObjects （メソッドは他のPageObjectsを返す）

・Need not represent an entire page （ページ全体を表す必要はない）

・Different results for the same action are modelled as different as different methods （同じアクションに対して異なる結果となる場合には異なるメソッドとしてモデル化する）

このデザインパターンで書かれたテストコードの利点は画面変更が発生した場合にテストコードの修正が最小限で済むことにあります。

3. テストすべき内容をインターフェースとして定義

３つ目は各画面で共通して必ずテストするものをインターフェースとして定義することです。

デザインパターンである程度テストコードの統一性は生まれますが、チェックすべきテストを書く・書かないはその人次第になってしまう事があります。

私はそれを防ぐために必要なチェック項目をインターフェースとして定義する事でテストの漏れをできる限り少なくなるようにしました。

public interface MyTestCaseInterface {
    public void testCheckUrl();          // URLのチェック
    public void testCheckPageTitle();    // ページタイトルのチェック
    etc...
}

サンプルコード

以下は参考までに私がテストを行ったときのパッケージ構成とテストコードのサンプルとなります。

パッケージ構成

jp.co.isoroot.sample.page        // ページオブジェクトクラス
jp.co.isoroot.sample.scenario    // シナリオクラス
jp.co.isoroot.sample.fixture     // データクラス

ページオブジェクトクラス

画面１つ１つをクラスとして定義します。

また各画面で共通の部分がある場合、ベースクラスを定義して各画面で継承させると良いでしょう。ただし、なんでもかんでも共通化しようとしてベースクラスが肥大化しすぎないように注意が必要です！

以下はログインページとトップページのサンプルコードです。

public class PageBase {
    protected WebDriver driver;
    public PageBase (WebDriver _driver) {
        this.driver = _driver;
    }
    /**
     * <title>要素のテキスト取得
     */
    public String getPageTitle() {
        return driver.findElement(By.tagName("title")).getText();
    }
    /**
     * URL取得
     */
    public String getUrl() {
        return driver.getCurrentUrl();
    }
}

public class LoginPage extends PageBase {
    public LoginPage(WebDriver _driver) {
        super(_driver);
    }

    /**
     * ログインページにURLアクセス
     */
    public HogePage access() {
        driver.get(ログインページURL);
        return this;
    }

    /**
     * ログインボタンクリック
     */
    public TopPage clickLogin(String _id, String _pass) {
        driver.findElement(ログインID入力フォーム).sendKeys(_id);
        driver.findElement(ログインパスワード入力フォーム).sendKeys(_pass);
        driver.findElement(ログインボタン).submit();
        return new TopPage(driver);
    }
}

public class TopPage extends PageBase {
    public TopPage(WebDriver _driver) {
        super(_driver);
    }

    /**
     * トップページにURLアクセス
     */
    public TopPage access() {
        driver.get(トップページURL);
        return this;
    }
    /**
     * ログアウトボタンクリック
     */
    public LoginPage clickLogout() {
        driver.findElement(ログアウトボタン).click();
        return new LoginPage(driver);
    }
 }

シナリオクラス

このクラスではページオブジェクトクラスを利用してテストするシナリオを定義します。

以下はログインページのURLとページタイトルをチェックするサンプルコードです。

public LoginPageTest implements MyOperationTestCaseInterface {
    WebDriver driver;
    public LoginPageTest() {
        driver = new ChromeDriver();
    }
    @Test
    @Override
    public void testCheckUrl() {
        LoginPage _login = new LoginPage(driver).access();
        assertTrue(_login.getUrl().equals(ログインページURL));
    }
    @Test
    @Override
    public void testCheckPageTitle() {
        LoginPage _login = new LoginPage(driver).access();
        assertTrue(_login.getPageTitle().equals("ログインページ"));
    }
}

補足：WebDriverの取得もFactoryクラスを作って切り替えられるようにするとより汎用的になります。

最後に

今回はWebアプリケーションの画面テストをする際に注意すべきこととして

テスト自動化の範囲
テストコードの記述ルール(デザインパターン)
テストケースの抽象化(インターフェース定義)することによるテスト漏れの防止

をご紹介しました。

テストコードを書くのはとてもコストがかかりますが、Seleniumのようなテストツールを上手く活用する事でテストにかける時間を少なくし、産性を最大限に引き出す事ができるきっかけの一つとなりますので、ぜひ活用してみてはいかがでしょうか。

Selenium WebDriverはC#、Java、Perl、PHP、Python、Ruby、Node.jsに対応。 ↩