2017/07/26 iOS Test Night #5 Tadashi Nemoto 手動リグレッションテストをE2Eテストに 置き換えてみて分かってきたこと 

自己紹介 • 根本 征 (github: tadashi0713) • Software Engineer in Test @mercari • モバイルアプリ・WEBアプリをぶり ぶり自動化 

#4で発表した内容 https://speakerdeck.com/tadashi0713/appiumkaraxcuitestnib ian-e-sofalsetameniswiftwoxue-bishi-metahua 

● 前回から対象のアプリをUS版→JP版に変更 ● 前回と同様、手動で行われていたリリース前のリグレッショ ンテストケースを自動化 ● iOS・Android共に外部連携したものを除く100%をE2Eテス トで自動化 ● 特に重要な購入・出品機能はパターンを増やして実装 ● iOSはXCTest UI Testで実装 最近までやっていたこと 

Bluepill を使って 1OS × 1 mac mini × 3 simulator で約30分 タイムアウトやリトライで安定的に実 行できるように ケースによって、実機での実行で行う テストも追加予定 

導入してみてから約1ヶ月、、、 ● 導入してみての効果 ● 見えてきた課題 

導入してみての効果 

導入した際の効果が見えやすい 他のレイヤーのテストに比べ、最終的なアプリの振る舞い をテストしているので、 ● QA合意のもと、手動テストに置き換えることができた ● どのようなテストをしているのかが見えやすい ○ 非エンジニアでも分かってもらいやすい 

アプリ全体に影響がでる可能性のある変更 ● Xcode・ライブラリの更新 ● アプリ全体に影響が出る変更 ● APIの大幅な変更(PHP7移行、他リージョンへの影響) リグレッションを恐れずに変更できるようになる きっかけになるのでは 想定外のケースでも自動テストが活用できた 

見えてきた課題 

ドキっ(実装途中に) UIテストで注意すべき点 手動テストを単純に置き換えない 

• 正しく〜ができていること • どこを、どこまでチェックできていれ ば正しくできている？ • 解釈しながら相談して実装したが、QA とのずれが出る可能性がある テストケースの期待値のずれ 

テストケースに明示的に書かれていなくても、暗黙的 に確認しているケース • (まだないが)レイアウト崩れ • 期待値に行くまでの過程で実はチェック していた箇所 • 選択項目など 

● 勉強会などで実際にUIテストを書いてもらうことで、どこまで チェックできるか・どのようなテストケースになればいいのか、 考えるきっかけになれば ● 手動テストではコスト上できていなかったパターン UIテストを意識して、テストケースを改善していく 

テスト区分戦略 (Maintenance、Fleakiness) • UI変更 • API変更 • 仕様に強く依存 

● Postmanを使ったAPI振る舞いテスト ● Webview ● UnitTest、FunctionalTest E2Eテスト以外で担保できる部分を増やしていく