受託開発プロジェクトで Appiumによるテスト⾃動化を試す 2016.3.23 @sumio_tym (TOYAMA Sumio) 1 Android Testing Bootcamp #1

⾃⼰紹介 • ⽒名: 外⼭ 純⽣ (TOYAMA Sumio) @sumio_tym (Twitter) / @sumio (GitHub) • 所属: NTTソフトウェア株式会社 • 業務内容: 社内Android関連プロジェクトの技術⽀援 • プライベート: •  STAR(テスト⾃動化研究会) •  @IT連載「スマホ向け無料システムテスト⾃動化ツール」 uiautomator/Appiumの回を書きました http://www.atmarkit.co.jp/ait/kw/smapho_testtool.html 2

お話しすること Androidアプリの受託開発プロジェクトで、 Appiumによるテスト⾃動化を試してみました。 その時に得られた知⾒を共有します。 3

話の流れ 1.  背景と⽬的 2.  試⾏対象プロジェクトについて 3.  やってみたこと 4.  得られた知⾒ • コスト⾯ • その他 5.  まとめ 4

話の流れ 1.  背景と⽬的 2.  試⾏対象プロジェクトについて 3.  やってみたこと 4.  得られた知⾒ • コスト⾯ • その他 5.  まとめ 5

背景 受託開発プロジェクトでは？ (定型的なテストを⼿動でやるのはダルい) 6 勉強会で聴くシステムテスト⾃動化事例: ⾃社プロダクト/サービスの話がほとんど

システムテスト⾃動化で良く⾔われること 「繰り返しテストする項⽬を⾃動化 しないと意味がない」 追加開発が⾒込めるなら意味がありそう 「⾃動化コストの⼤部分を占めるのは、 テストスクリプト実装コスト・ メンテナンスコスト」 まずは、メンテナンスしやすさに気をつけて実装したとき の、実装コストを計測してみよう 7

試⾏の⽬的 • 試⾏を通じて、以下の知⾒を得る •  どれくらい繰り返せばペイするのか？ •  テストを書くときに気を付けるべきことは何か？ ターゲット: 複数回の機能追加が⾒込める受託開発プロジェクト ⾃動化対象: 正常系の画⾯遷移確認(毎回確実に実施する) ※回帰テストの⾃動化は諸事情によりパス 8

話の流れ 1.  背景と⽬的 2.  試⾏対象プロジェクトについて 3.  やってみたこと 4.  得られた知⾒ • コスト⾯ • その他 5.  まとめ 9

プロジェクト概要 • ⾳声認識・⾳声読み上げ機能を使った Androidアプリ (Android 4.3向け) • 「設定画⾯」の追加を⾏う⼩規模なプロジェクト ※前回納品時に基本機能は全て完成済み • 正式なテストは全て⼿動テスト ※⾃動化した項⽬も含めて全て⼿動で実施 10

アプリの画⾯遷移 11 ログイン ダイアログ 起動モード選択 チュートリアル チュートリアル チュートリアル チュートリアル ①〜④ メイン画⾯ (⾳声認識・ 読み上げ機能) 設定画⾯ 戻る 次へ 設定 左右スワイプでも ①〜④間の移動が可能 ImageButton を押して選択

⾃動化に使ったツール • Appium 1.4.13 http://appium.io/ • 使⽤⾔語: Java 12

⾃動化の体制 13 開発プロジェクト テストコード実装 (Androidエンジニア) 外⼭(技術⽀援) レクチャー テストの⼀部実装 Appium初⼼者

話の流れ 1.  背景と⽬的 2.  試⾏対象プロジェクトについて 3.  やってみたこと 4.  得られた知⾒ • コスト⾯ • その他 5.  まとめ 14

教育 1.  ミニ勉強会 (2時間) @ITの記事を教材にポイントを絞って解説 2.  環境構築・⾃習 (6時間) 記事のサンプルアプリを元に動かしてみる 3.  ペア作業 (2時間) PageObjectパターンを意識して1つテストを書く • Pageの分割例 • 遷移先ページが異なる場合は別メソッドに • etc. 15

(補⾜)Page Objectパターン https://github.com/SeleniumHQ/selenium/wiki/PageObjects • 1画⾯(Page)＝1クラス • その画⾯でできる 「ユーザーにとって意味のある操作」 をメソッドとして定義 •  テストスクリプト側は、ここで定義したメソッドのみ使う • クラス＝メソッドの集合 •  「操作できること」が変わるなら、 同⼀画⾯でも別クラスにした⽅が良い •  ダイアログ •  Navigation Drawer •  etc. 16

設定画⾯ ⾃動化範囲のピックアップ • ⼿動で⾏うテスト項⽬表から、以下をピックアップ •  新しく作った「設定画⾯」内正常系シナリオ •  既存機能の画⾯遷移正常系シナリオ (⾳声認識・読み上げ系は除外) 17 ログイン ダイアログ 起動モード選択 チュートリアル チュートリアル チュートリアル チュートリアル ①〜④ メイン画⾯ 設定画⾯ 戻る 次へ 設定 ※ 部分を⾃動化

テスト実装 • Page分割⽅針を決めて、ひたすらテストを書く • 同じPageを複数⼈で担当しないように⼯夫 •  「設定画⾯」係と「その他」で分担 18

話の流れ 1.  背景と⽬的 2.  試⾏対象プロジェクトについて 3.  やってみたこと 4.  得られた知⾒ • コスト⾯ • その他 5.  まとめ 19

得られた知⾒(コスト⾯) (1/2) 20 前提: 以下のコストはゼロとみなす •  ⾃動化の初期費⽤(学習コスト、マシン購⼊費⽤など) •  ⾃動テストの実施コスト(無⼈でも実⾏できるため) ⽐較対象 •  ⼿動テストの実施コスト(稼働)[⼈時] •  ⾃動テストの開発コスト(稼働)[⼈時] 結果 テスト件数 (カバレッジ) ⼿動テスト 実施コスト ⾃動テスト 開発コスト ⾃動÷⼿動 今回の⾃動化範囲 51件 (5.8%) 1.0h 14.0h 14.0 ⾃動化後 14回テストしないと ペイしない！

得られた知⾒(コスト⾯) (2/2) • 少しの改造で、更に⾃動化できる箇所を抽出 •  ⾃動化済みの操作の組み合わせだけで実現できるもの (Page Object実装は変更不要) •  新しく⾃動化が必要な操作が1つだけで済むもの • 抽出したテスト項⽬の⾃動化コストを⾒積ってみた 21 テスト件数 (カバレッジ) ⼿動テスト 実施コスト ⾃動テスト 開発コスト ⾃動÷⼿動 今回の⾃動化範囲 51件 (5.8%) 1.0h 14.0h 14.0 更に範囲を広げた場合 (※) 656件 (74.5%) 9.0h 24.0h 2.67 ⾃動化後 3回テストすればペイする(はず) ※本当にそうなるかは、次回計測してみます。

得られた知⾒(その他)① (1/2) ImageButtonの操作が⾟い •  操作対象コンポーネントの識別に使いやすいもの •  text (表⽰⽂字列) •  hint •  contentDescription •  リソースID ※Android 4.4以降のみ •  どれも無いと「左からn個⽬のImageButton」 といったUI変更に弱い条件にせざるを得ない 22 操作対象コンポーネントには、 どれか1つは値を設定しておくと楽できる

得られた知⾒(その他)① (2/2) コンポーネントの識別に使うのはどれが良いか? 23 開発者が勝⼿ に付けてOK? 対応API text (表⽰⽂字列) × 制限なし hint (EditText未⼊⼒時のヒント) × 制限なし contentDescription (⾳声読み上げに利⽤) × 制限なし リソースID (R.id.xxxx) ○ 19以上 •  API 19以上: 操作しそうなものにリソースIDをつければOK •  API 19未満: UI/UX検討時点でcontentDescriptionまで 考えておく(後から付けるのは困難)

得られた知⾒(その他)② テストを書く⼤変さの度合い(⼤変な順) 1.  新しい(⾃動化していない)画⾯の実装 2.  ⾃動化済み画⾯の、新しい操作の実装 3.  ⾃動化済み画⾯/操作の組み合わせでOKのもの ⾃動化対象は、以下の⽅針で抽出するのが良さそう 1.  ⽬的を達成する最低限の項⽬を抽出する 2.  「1」で操作する画⾯遷移内で確認できる項⽬ まで⼿を広げる 24 ※Page Objectパターンで実装する前提です。

まとめ •  受託開発プロジェクトでAppiumによるテスト⾃動化を試⾏ してみました •  ⾊々⼯夫すれば、現実的な繰り返し回数で初回コストは 回収できそう •  コンポーネントを識別できるようにする⼯夫 (設計時から検討が必要なもの有り) •  テスト項⽬抽出の⼯夫 (画⾯数を増やさずに可能な範囲で⾃動化する) •  Page Objectデザインパターンの適⽤ •  今回試せなかったことも •  メンテナンスコストを考えたときにペイするのか？ •  回帰テスト⾃動化に⼿を出すとどうなるのか？ 25

26 ご清聴ありがとうございました ご質問・コメント歓迎です！