テスト自動化のエキスパートが集う国際カンファレンス「Selenium Conf Tokyo 2019」が4月中旬に東京で開催されました。本稿で紹介させていただくセッションはAlissa Lydon、Samantha Coffman氏による「ヘッドレスでSeleniumテストを高速化」です。ヘッドレスブラウザを活用することにより、より高品質でより高速なデリバリーを実現できる継続的テストソリューションとは、いったいどういうものなのでしょうか。
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
本セッションのスピーカーはSauce Labs社のプロダクトマネージャーSam Coffmanと、プロダクトマーケティングマネージャーAlissa Lydonです。
テストが開発サイクルにおいて「シフトレフト」を施策として採用するのは、開発者はコードの品質のフィードバックを早期に必要とするからであり、テスターは開発速度を低下させることなく早い段階でテストを組み入れることを目的とします。フルブラウザーでのテストは、開発ライフサイクルの後半のあたりで、完全なUIの互換性を確認するためには重要です。しかし、早い段階での導入は開発速度を低下させ、メンテナンスコストを増加させます。
ヘッドレスブラウザを使用することにより、Seleniumによるテストを開発ライフサイクルの早い段階で高速に実施できるという、大きなメリットがあります。 開発ライフサイクルの全て段階でフルブラウザによるUIテストをするということをやめることで、開発者はコード品質のフィードバックを得て、テストインフラの維持コストを全体的に軽減する軽量な選択肢となります。クロスブラウザーテスト戦略と組み合わせれば、ヘッドレスにより、より高品質ソフトウェアをより速くデリバリーし、継続的テストソリューションとなります。
#開発スタイルや開発メンバの役割の変化
使用するIT技術やビジネス要求は年々複雑となっており、システムは複雑化し従来のスタイルでは品質を保証するのは非常に困難になってきました。品質リスクに対応するために、開発スタイルや開発メンバの役割に大きな変化が求められます。
##アジャイル開発の増加
ソフトウェア開発はより難易度が高くなってきており、昨今はアジャイル型の開発が採用されることが多くなりました。従来のウォーターフォール型の開発に比べて、短いインターバルで反復開発することによりステークホルダーからのフィードバックがタイムリーに受けることができる反面、テストの回数や工数は大きくなりました
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
##シフトレフト
開発プロジェクトを進めていく上で必ずと発生する問題が、開発工程の遅れです。シフトレフトとは、品質を損なうことなくテスト工程を前倒しすることによって開発全体の時間軸を左へ移すための取り組みです。近年ではCI（継続的インテグレーション）への関心も高まり、自動テストをパイプラインに組み込むことが増えてきています。
##開発メンバの役割の変化
テストエンジニアにはどのような変化があったのでしょうか。従来テスト工程を主戦場としていたが、QAエンジニアとして上流の工程から開発全体の品質を監督する立場となった。
また、開発者の役割に関しても変化があった。テスターへ引き渡す前のUI疎通テストは従来のウォーターフォール型であれば手動でもやりくりはできますが、アジャイル開発やシフトレフトによりUI疎通テストの回数が増加し手動ではもはや対応が困難になります。それに伴い開発者にもUI疎通テストを自動化して実行することが求められます。
#ヘッドレスブラウザが解決策となるか
このような開発スタイルや役割の変化の中でテストに対する課題をヘッドレスはどのように解決するのでしょうか。
##UIを使わずに実行が可能
従来のフルブラウザでの操作にはVM(OS)やGUIやブラウザが必要です。
しかし、ヘッドレスブラウザはバックグラウンドで実行するため、ブラウザのみが必要でVM(OS)やGUIは必要ありません。
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
##コスト対効果が高い
VM(OS)やGUIを必要としないということは、H/Wスペック(CPUやメモリ)を消費しないため、軽量に実行することが可能となります。例えば、GUIでブラウザの複数のテストを同時に実行する場合には、多くのH/Wスペックを消費するため複数のVM(OS)を立てる必要があった。それに対して、ヘッドレスの場合は、VM(OS)やGUIを必要としないため、１つのVM(OS)上でコンテナ化することにより省スペックで実行が可能になります。
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
#どこでヘッドレスを活用すべきか
ヘッドレスの特徴を踏まえてどこで使用するのが適切なのかを見ていきましょう。
##不具合箇所の修正確認に使用
開発者が不具合を再現する時に自動化テストを作成する。この時にはGUIモードで作成しておいて、その後ヘッドレスモードに切り替えても再現することを確認します。その後、修正をしてその修正確認をヘッドレスでします。また、これらのヘッドレステストを積み上げて疎通確認用に再利用も検討しましょう。
##疎通確認用に使用
クリティカル機能の疎通や回帰テストなどにヘッドレステストを用意していることにより、修正を構成管理レポジトリにコミットする前にデグレがないかを確認できます。もちろん修正する前にも実行することにより修正前から発生していた障害なのかどうかも確認が可能となります。
#どこでヘッドレスを活用すべき「でない」か
##フルブラウザテストの全てを代替できない
ヘッドレスで画面ショットも取る事ができるなど何かと便利ではあるものの、だからと言って、最終的には人が確認する必要があるため、GUIでのブラウザテストをなくすことはできません。
##ChromeとFirefoxに限られる
現時点でブラウザの機能としてヘッドレスモードをサポートしているのは、ChromeとFirefoxだけに限られています。逆に言えば、IEやSAFARIは未対応であるためヘッドレスは使用できません。
#デモ実行
デモのシナリオはショッピングサイト(下記イメージ参照)でキーワード検索し、買い物カゴに追加して、買い物カゴのページに正しい情報が表示されているかを確認する疎通テストを実行します。
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
下記のイメージはその実行イメージです。
左半分が疎通テストスクリプトで、右半分は実行ログを出力しているDOS画面です。疎通テストはRubyとRuby用のフレームワークであるWatirを使用しています。8つのテストを並列実行した結果のログがDOS画面に表示されています。並列実行であったため数十秒で全テストの実行完了して、フィードバックをクイックに確認できました。
出典： Se Conf Tokyo Team, Youtube, URLは末尾のDay1 Trac1を参照
#最後に
今回紹介されたヘッドレスの活用をしていないプロジェクトは多いように感じますが、適切な工程やテスト対象に組み入れることで、より高品質でより高速なデリバリーを実現できる継続的テストソリューションになりうると思います。
#参考リンク
##Selenium Conf Tokyo 2019のセッションタイムテーブル
https://conf.selenium.jp/uploads/1/2/0/2/120229834/timetableja.pdf
##Selenium Conf Tokyo 2019のセッション視聴
###Day1 Trac1
https://www.youtube.com/watch?v=DBpb18iURu4&t=18s
###Day1 Trac2
https://www.youtube.com/watch?v=ifE9ZveJ3Qg
###Day2 Trac1
https://www.youtube.com/watch?v=iigvNlGlk9g
###Day2 Trac2
https://www.youtube.com/watch?v=faRHUmD-Ozc