SHIFTのE2Eテスト自動化ツールの秘密に迫る！

こんにちは！スマートな社会を目指してQA (Quality Assurance) をしている矢野です。

本記事では、Seleniumを用いてSPA (Single Page Application) のSUT (System Under Test) に対して、テスト自動化を導入した方法を、実例ベースでご紹介させていただくのと同時に、SHIFTのE2Eテスト自動化ツールについて簡単にご説明させていただきます。

なぜE2Eテスト自動化でSeleniumなのか？

Webアプリの操作やテストの自動化をしたい！という場合に、Seleniumというツールは多くの方の頭に浮かぶのではないでしょうか？

WebアプリのE2Eテスト自動化においても比較的歴史の長いOSSで、Selenium WebDriverはW3Cで標準化されていますし、Webで検索した場合の情報や、書籍も沢山あるので白羽の矢が立ちやすいツールです。

対応ブラウザのバリエーションも豊富で、複数のドメインにまたがるテストや複数のユーザでのテストなど、機能的にできることが非常に多いのも特徴で、Seleniumならばテストケースを自動化する際のさまざまな要件を満たすことができる点は強みであると思います。

SeleniumでSPAのテスト自動化を行うときの問題とは？

さまざまな要件を満たすことのできるSeleniumですが、SPAのテスト自動化を行う場合の問題として、真っ先に非同期処理への対応の問題が挙げられることかと思います。

SPAの場合、ユーザの操作によってページが遷移することなくインタラクティブにページ内の要素が書き換えられていくので、例えばテストの中で、とある要素が出現するのを待つ場合、待機処理を明示的に書く必要があります。

この結果、テストコード側でWait処理やマジックナンバーの大量生産が行われるという問題があります。

また、SPAのテストを書く場合に限った問題ではないですが、テストコード上でWebDriverの操作を細かく書いていく必要があるので、記述量が増えやすく、可読性もあまり良くありません。

SHIFTのE2Eテスト自動化ツールRacineとは？

Seleniumについて軽く整理したところで、SHIFTで開発しているRacnine(ラシーヌ)という、E2Eテスト自動化ツールを簡単に説明させていただきます。下図のようにSeleniumやAppiumといった、各種OSSを内包しているツールです。

テスト自動化の依頼主であるお客様からの要件次第では、別のテスト自動化ツールをご提案させていただくこともありますが、Webアプリのテスト自動化では、Seleniumの利点を考慮しRacineを用いたテスト自動化の導入実績も多いです。

Racine自体はビルドツールで管理されているので、Seleniumの導入時によく指摘されるセットアップの困難さは問題にならず、テストランナー、テストレポートツールを選定するコストも不要となります。

またOSSを組み合わせたツールなので、OSSのメリットを最大限利活用できベンダーバインドがありません。

テストコードはSelenideを使用する場合Javaで書く必要が出てきますが、Seleniumの苦手とするSPAの非同期処理への対応も問題なく、テストコードも非常にシンプルかつ可読性のあるコードが書けることが特徴です。

またRacineにはモバイルアプリの操作を自動化するAppiumも入っているので、Webアプリだけでなくモバイルアプリのテストも自動化することが可能です。 Racineについては過去の記事にも書いてあるのでそちらも合わせてご覧いただけると幸いです。

SPAのテスト自動化における注意点とは？

SPAに対して実際にテストを書くときに注意したことを2つほどご紹介します。

１つ目の注意した点は待機処理についてです。

Selenideの機能で要素に対する待機時間とポーリング間隔のデフォルト値が設定できるので、基本的にはSPA対応のための待機処理をSeleniumのように明示的に書く必要はありません。

とはいえ、デフォルト値では待機時間が足りないような要素も実際のテストの中には存在しました。そういった場合にはSelenideにwaitUntilやwaitWhileといったメソッドがあるので、それらを使用し待機処理も一行で書くことが可能になります。

例えば、とある要素を最大1分間出現するのを待つ場合は次のような書き方になります。

２つ目の注意した点は要素を指定するロケータについてです。

E2Eテストを自動化するときには、要素をロケータによって指定してアサーションや入力操作などを行います。

CypressというE2Eテスト自動化ツールのガイドにも書かれているように、tagやclassといったものは変更が入りやすく、Webアプリの開発に使用しているフレームワークによってはidも、もはや固定化されないものとなっておりロケータに適していません。

実際にE2Eテストを導入したSUTもidが固定化されないものでした。

加えて意味のあるロケータにあまりならないという点もあります。例えばE2Eテストで要素のidが変わったことを検知したいというケースは稀なのではないでしょうか？

要素のテキストをベースにロケータを指定する方法ならば、画面上のテキストに変更が加わった場合にテスト側で検知することが可能になります。

Cypressのガイドにもあるように、テキスト情報の変更を検知しなくても良い場合にはカスタムデータ属性を使用することが推奨されますが、テスト自動化のために常にプロダクトコードに修正が入るとは限らないので、実際に多くのロケータにはテキスト情報を利用しました。

例えばSelenideで記述する場合は次のような書き方となります。

テスト自動化の成功とは？

昨今の開発現場ではアジリティが求められており、QAやテストでもアジリティ獲得のためのテスト自動化のニーズが増えていることかと思います。

実際の導入事例では、手動テストで120分ほどかかっていたテストを、テスト自動化によってわずか5分程度で実行できることを確認しました。またSPAにおいてもSeleniumを用いたSelenideで書けば、テスト自動化ができることが確認できました。

これらの結果は、テスト自動化の検証と導入としては成功かもしれませんが、テスト自動化の成功と果たして言えるのでしょうか？長期的な意味でのテスト自動化の成功というのは、導入した直後では判断できません。

例えば、1年後にも自動テストがシェルフウェアにならずに品質を確認する手段として使われ続けている必要があると思います。

本記事で詳細は割愛させていただきますが、自動テストの効果を最大限発揮し、使い続けるためにはテストをCI上で実施しテストレポートを自動的にデプロイすることや、テスト結果のサマリーを通知するといった、テスト結果の高速なフィードバックと品質の可視化も大切なことです。

テスト自動化の必要性については、和田卓人氏が JaSST’20 Niigataでご登壇された時の内容をシフトモでもまとめていますので、ご覧いただければ幸いです。

宣伝

品質保証のためのテストが手動で行われていて、リリース速度や頻度のボトルネックにはなっていませんか？

テストを自動化はしたけど導入コストをかけただけで、結局何にも使われないお飾りのツールになっていませんか？

SHIFTでは本記事でご紹介したRacineだけでなく、テスト自動化の導入に際しお客様の要望をヒアリングして、最適なテスト自動化ツールをご提案しテスト自動化のご支援をいたします。

アジリティが求められるDX時代の開発現場においては、テスト自動化はもはや欠かせない手段の一つです。

テスト自動化支援についてはこちらからご相談ください。

テスト自動化支援 サービスのご紹介| 株式会社SHIFT

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/