こんにちは、QAエンジニアの武田です。
去年の健康診断で、メタボ予備軍と言われ、キックボクシングを始めたのですが、思うように成果に繋がっていません。。。
もうすぐ今年の健康診断が迫っているので、何かいい減量方法があったら教えて下さい🙇
さて、今日は、前回、テスト自動化の取り組み初期についてご紹介してから約2年が経過した今、どのように運用しているか、その成果など、テスト自動化の現状をお話したいと思います。
Before
まず、前回紹介した際の構成がこちらです。
テストは、 Jenkins から 定時点 でリクエストされ、 ローカルPCにつないだ実機 で実行していたのですが、本格的に運用していくには解消すべき大きな課題が2点ほどありました。
1点目は、 環境のメンテナンスが必要 ということです。
テスト実行のリクエストとテスト結果をSlackに通知する役目をJenkinsが担っていたため、Jenkinsが動いているローカルPCのバージョンアップやJenkins自体のバージョンアップ、コマンドの追加・修正などを自分たちでメンテナンスする必要がありました。
頻繁に発生することではないですが、バージョンアップが漏れているとセキュリティ事故につながる場合もあり、気の抜けない作業です。
2点目は、 特定の端末、アプリでしかテスト出来ない ということです。
テストを実行するには、あらかじめ、Jenkinsが動いているローカルPCにテストアプリをダウンロードして、端末を接続しておく必要があり、違うアプリのバージョンや端末でテストを実行したい場合は、これらの準備を都度行わなければいけませんでした。
また、端末は開発時のデバッグ作業や手動でのテスト等でも使用しているため、テストしたい端末でテスト出来ない、実施する端末が偏ってしまうという状況になっていました。
After
これらの課題を解決した現在の構成がこちらです。
Jenkinsを脱却し、テスト実行環境をBrowserStackに移行することで、ローカルPCを排除し、環境のメンテナンスにかかる負担を排除しました。
それでは、取り組んだ内容について、もう少し詳しく説明したいと思います。
Magic Hand(Slack App)の開発
Jenkinsの代わりにテスト実行のリクエストとテスト結果をSlackに通知するためのSlack App、 Magic Hand をGoogle Apps Scriptで開発しました。
Magic Handを開発したことで、独自のSlash Commandから利用者が 任意のタイミング で、 任意の端末・アプリ を選択してテスト実行をリクエストすることが可能になりました。
また、開発言語として、Google Apps Scriptを採用したことで、サーバーのメンテナンスやコストの負担がかからないこともポイントです。
余談ですが、ノハナ（といってもほとんど武田ですが）では、Google Apps Script製のツールが多く活用しています。これについては、また別の機会に紹介できればと。
Magic Podの採用
自動テストの中核となるテストを実行する部分は前回から引き続き Magic Podを採用しました。
テストを実行するためには、テストコードの作成とテストを実行する環境の構築が必要不可欠ですが、Magic Podは、それらをまるっと担ってくれるオールマイティなサービスです。
テストコードの作成では、Magic Podに組み込まれたAIエンジンがテスト対象のアプリ(画面)から自動的にボタンやテキストフィールド等の要素を認識してくれるので、あとはビジュアルプログラミング言語のように認識された要素とアクションを選択していくだけ、小難しいプログラミングは必要ありません（失敗に強い安定するテストコードを作るためには、多少のプログラミング知識があった方がよいとは思います）。
テスト実行については、ローカル環境のほか、Magic Podに用意されているクラウド環境(シミュレーター)や対応している外部のクラウド環境(実機)でテストを実行することができます。
Magic Podは、 ノハナの自動化において必要不可欠で、出会っていなければ、「自動化したいなぁ、でもプログラミングできないしなぁ、環境構築とかよく分かんないしなぁ」と悶々として、とうてい現在のような状態には至っていなかったと思います。
BrowserStackの導入
Magic Podからテストの実行ができるクラウド環境には、 Remote TestKit や SauceLabs 、 HeadSpin 等がありますが、中でも
BrowserStackは、比較的低コストでスタート出来ることから、採用を決めました。
ダッシュボードからテスト実行時の動画やスクリーンショット、デバイスやネットワーク、Appium等の各種ログを確認することができるため、エラーが発生した際の調査にも役に立ちそうです。
結果
現在、iOSアプリ、Androidアプリともに回帰テストのテストケースの ２０% 程度を自動テストで実行しており、Androidアプリの回帰テストでは、手動での実行工数を １６５分 削減することが出来ました。
今後は、回帰テストでの機能の網羅性と自動テストでのカバー率を上げていきたいと考えています。
この記事を書いた人
