Node.jsで書いたSeleniumのコードをマルチデバイス対応させる

はじめに

普段はとある企業でフロントエンドを担当しています。
たまにバックエンドやインフラもやりますが、今回はテストシステムの構築から始めたのでフロント＆インフラが絡むお話です。

背景

社内開発で、リリース前テストは要望の上がったユーザー部門で行ってもらっていましたが、いろいろ対応しなければいけないパターンが出てきたことからテストの自動化を進めていきました。

課題

テストがそもそも負担大

私のいる会社では社内の担当部署で動作チェックを行ってもらい、問題なければリリース・・・というプロセスを踏んでいます（もっと良いフローはあると思う）
もちろん担当部署には他の仕事があるのでテストばかりやっているわけにはいきません。

機能・アプリの増加によるテストケース増加

これはテストを網羅的に実施しようとすると永遠に付きまとう問題かと思います。
手作業でテストを行っていたのでなおさら負担は大きいものでした。

テストでマルチデバイス対応が必要になっていた

iOSのある特定のOSバージョンでしか発生しないバグが発生するなど、ユーザーテストでは網羅に限界のある内容が出てきていました。

考えること

マルチデバイス間でのテストケース共通化

ここの選択肢を誤ると後で書き直しになったり、モバイルテストとブラウザテストを書き分けるという地獄を経験することになるので慎重に選びました。
Androidでのみテストを行うのであればPlaywrightもアリですが、iOSのテストも含まれていため今回は対象外としました。

最終的にSelenium Webdriver+Appiumを選びました。
おそらく無難なのはpython+Selenium+WebDriver辺りですが、私自身pythonを書き慣れていなかったことからNode.jsのselenium-webdriverを採用しました。

selenium-webdriverとは→
https://github.com/SeleniumHQ/selenium/tree/trunk/javascript/node/selenium-webdriver#readme

デバイス問題（ローカル？クラウド？）

マルチデバイステストを考える上で考えられる選択肢は以下の2つです

1. クラウドサービスの利用：Firebase Test LabやAWS Device Farmなど
2. ローカルで実機を一括管理

2.はセキュリティや安定性の面で現実的ではないと判断。
1.ではいくつかのサービスがありましたが、社内インフラとしてAWSが推奨されていたこともありAWS Device Farmを採用しました。
https://docs.aws.amazon.com/ja_jp/devicefarm/latest/developerguide/welcome.html

テストコードを書く期間

その後の案件状況からおよそ3ヶ月で自動テストシステムの構築・約400ケースのテストコーディングを終わらせる必要がありました。

実装したテスト

• E2E→UT,ITは未実装
• 画像回帰テスト(Visual Regression Test)→E2Eの実施中にスクショを撮り、本番環境との差分をReg-CLIでレポート化

実装のためにやったこと

• テスト対象のプレビュー環境をAmplify Hostingで用意。CloudFront+WAFでセキュリティ対策
• AWS Device FarmでのAppium利用→testspec.ymlの調整やテストリソースのデプロイ方法など、非常に情報量が少なかった。ある程度までは下記ページを参考にし、Classmethodの方へ質問しながら構築を進めた。
  https://docs.aws.amazon.com/ja_jp/devicefarm/latest/developerguide/test-types-appium.html
• テストコーディングはGithub Copilotをフル活用→体感4割くらい採用していたと思う。ローカルで動かして適宜調整。
• ブラウザ側のテストはSelenium Gridを導入。CodeBuild上でコンテナ展開し、Chrome,Edgeのテストを実施
• E2EのアサーションライブラリとしてはレアだがフロントをVue.jsで書いていたこともあり将来ITを書く可能性があったことからVitestを採用。
• テストレポートはHTML+junitを出力させ、パイプラインの結果としてjunitを返却。テスト内容のプレビュー用にHTMLをS3上でホスティング。

大変だったこと

DeviceFarmの情報が古い or 少ない

今回のマイナーな構成にフィットする情報が非常に少なかった。
見つけてもAppium2の情報だったりでCapabilitiesの記法でかなり苦戦した。

AndroidとiOSでテストコードに若干の調整が必要

恐らくラッパーライブラリを利用しているからだと思われるが、Androidで成功する動作がiOSだと認識しないことが多々あった。注入する環境変数からデバイスを識別させ、動作をコールバックで分岐させた。

良かったこと

マルチデバイステストの実施内容を動画として残せる

DeviceFarmではテストの実施結果を動画として保存してくれます。
スクリーンショットでの差分はReg-CLIに任せ、異常があったら動画をチェックしどこでおかしくなっているのかを後から見返せます。

テストコードを共通化できた

多少の調整は必要でしたが、環境・デバイス毎にテストコードを書き直さずに済むのは大きかったです。

担当部署の負担を大幅に減らせた

手作業で行っていたテストを自動化し、テストレポートの点検と一部チェックをしてもらうだけで済むようになったのでテストの負担を大幅に軽減できました。

テストコードを書くことで予期せぬ不具合を見つけられた

実際にテストを書いてチェックしている最中「ここ変だな？」というバグを何個か発見することができました。
品質向上という面でもテストを書くのは良さそうです（ITやUTだと更にいけそうだけど書く量が多いので今後検討）

さいごに

Seleniumなら大人しくpythonで書けば良かったとも途中思いましたが、普段から使っている言語で複雑なテストシステムを構築できたのは良い経験になりました。
今後はDevicefarmの運用やコスト改善を図っていきたいですね。