AppiumからXCUITestに変え、そのためにSwiftを学び始めた話

https://testnight.connpass.com/event/54316/

Transcript

1. 2017/05/22 iOS Test Night #4 Tadashi Nemoto AppiumからXCUITestに変え、 そ ためにSwiftを学び始めた話
2. 自己紹介 • 根本 征 (github: tadashi0713) • Software Engineer in Test @mercari • 4月からQA・SETチームとして活動 • UI・E2Eテスト自動化がメイン • テスト管理ツールを作りたいと思って色々チャレンジしてい る
3. #2で発表した内容 https://speakerdeck.com/tadashi0713/ appium-xcuitest-drivertocihuan-jing
4. 最近までやっていたこと • ターゲットアプリ リリース前に基本機能が正しく動作してい るかリグレッションテストを手動で行っていた • 繰り返し作業が多い・リリースするタイミングが増えたため一 部自動化を検討 • iOS・Androidで50%自動化目標 • Appiumを使って挑戦してみた
5. 結局どうなった か
6. Appiumをやめて(iOS) XCUITestに変えた
7. 理由そ 1： Accessibility付与 • ターゲットアプリに Accessibilityが振られている部分 少なかった • 付与しながらテストを書いていく事が求められた • しかしAppium 場合、iOSレポジトリでAccessibilityを振 りながら、また別 レポジトリでテストを書く必要があった • これが結構大変だった
8. 理由そ 2： 動作速度・安定性 • 当時xcuitest-driver 安定していない部分もあった • xcuitest-driver 場合Xpathを使うと動作が遅くなる • 動作速度が遅いとそ 分全体 実装速度も遅くなってい くなと書いていて感じた
9. 単純に思ったこと Appiumも実際に XCUITestを動かしている XCUITestでいい で
10. 試しに書いてみて とてもよかった
11. Accessibility付与問題 ？ • 1つ レポジトリでAccessibility付与・UIテスト実装ができ る • レコーディング機能で付けたAccessibilityがきちんと動作 できるか確認できる
12. 動作速度・安定性問題 ？ • 実行速度 Appiumと比べると早かった印象 • もちろんUIテストな で時間 とられやすい • システムアラートやWebviewも処理できた • waitもPage Object Patternを使ってうまくでき、安定 して実行することができた
13. ほぼ未経験だが Swift 挑戦しながら書いてみようȋ
14. 約1ヶ月半かけて XCUITestでEnd to Endテストを実装
15. Jenkins & 社内 mac で実行環境を用意 Chatから実行できるように
16. QAエンジニアと協力して リリース前 リグレッションテスト 50%自動化に成功 仕様・UI 変更にも追いついていく ことができた
17. しかしそ アプリ 諸事情により開発中断 もうほぼアップデートされること なくなった
18. 失ったコード5029行 無価値になったかと思った
19. 実際そんなこと なかった 残ったも 多かった
20. iOSをテストする上で 必要な知識が学べた
21. • 知らないといけないこと • Xcode、関連コマンド • Unit Test どうなっている か(XCTest) • fastlane • 知っておくと便利なこと • 並列実行(Bluepill、pxctest) • snapshot
22. • ノウハウもたまった • XCUITestで Page Object Pattern • テストデータ生成 • ど くらい工数をかけれ ど くらい自動化できるか
23. 違うチームでテスト自動化 導入が 検討されることがでてきた
24. UIテスト自動化に興味 ある QAエンジニアが出てきた
25. 定期的に勉強会を実施
26. これもある程度 レベルまで UIテストを実装・導入したからこそ 出た良い影響かなと僕 思いました