2017年7月1日、東京ガーデンテラスのヤフー株式会社 にて、日本Seleniumユーザーコミュニティ 主催の「Selenium Committer Day 2017」が開催されました。今回は3名のSeleniumコミッターを招き、今後のSeleniumの動向や、さまざまなツールを併用したテスト事例の紹介、そしてコミッターとのQ&Aパネルディスカッションが行われました。また、計4本のスポンサーセッション・公募セッションも設定され、会場で行われた懇親会も含め、非常に充実した勉強会になりました。
Jim Evans ―Seleniumの次に来るのは何か？（What’s Next For Selenium?）
1番手であるJim Evans氏は2010年からSeleniumのプリンシパルコントリビュータを務め、とくに.NETバインディングやIEドライバーの開発で貢献してきました。今回のセッションは、2004年に開発されてから現在までのSeleniumの足跡を振り返り、その上でSeleniumの今後について発表しました。本記事では、Seleniumの今後の方向性について語られた部分を中心に記載します。
Jim Evans氏
Selenium 4.0 ―W3C仕様に準拠したリリース
W3C（World Wide Web Consortium） という団体があり、そこでHTMLやCSSなどのWeb技術の規格が策定されています。Selenium 4.0からは、このW3Cの仕様に準拠する形でリリースされる予定になっています。
これにより、ブラウザベンダーがW3Cの標準に合わせて、それぞれドライバーを提供・メンテナンスするようになります。ブラウザを一番よく知る人たちが、ブラウザを自動化するツールを提供・維持する形が望ましいのです。Seleniumはオープンソースプロジェクトですが、ドライバーの中身に関してオープンソースにするかどうかは、各ブラウザベンダーに委ねられます。Seleniumがオープンソースでなくなる、ということではありません。
Seleniumのこれから
中期的に考えると、Seleniumプロジェクトはスリムになっていく方向で進んでいくでしょう。コードの量を減らし、バインディングされる言語も限られてくると思います。ただ、実際どういった形で継続されていくのかはわかりません。たとえばドキュメンテーションひとつとっても、現在あまり良い状態ではないということはわかっています。レコード・プレイバックツールのSelenium IDEやSelenium Builderも最近メンテナンスできていません。しかし、状況を良くしていくにしても、時間が必要です。これはあくまでもボランティアプロジェクトですから、常に人手が充足しているというわけではありませんし、貢献しているメンバーが興味を持っていないプロジェクトについては、どうしても後回しになってしまうのです。
Seleniumが誕生した2004年から13年間で、本当にいろいろなことがありました。世界中に数百万人のユーザが存在するプロジェクトになりましたが、まだまだ拡大していくのではないかと考えています。新しいものがどんどん現れるといいですね。
'
Marcus Merrell ―SeleniumとBrowsermobを活用したE2Eテスト分析（Using Selenium and Browsermob to Test Analytics End-to-end）
2番目に登壇したMarcus Merrell氏は、QAエンジニアとして長いキャリアがあり、ここ数年は、RetailMeNot社の技術責任者として、ユーザー駆動機能開発のマネジメントも行っている方です。
Marcus Merrell氏
Software Freedom Conservancy
初めにSoftware Freedom Conservancy という団体について触れさせてください。この団体はブランディングやコピーライトなどのオープンソースの管理をしているNPO団体で、非常に限られた予算で活動しています。SeleniumプロジェクトはこのSoftware Freedom Conservancyの支えにたいへん助けられており、たいへん感謝しています。
ユーザアナリティクス
Webサイトを訪れるユーザがどのように行動を分析するGoogle-Analytics を使うことで、企業はユーザがどのようにサイトを移動するかがわかります。
こうした分析で得た、ユーザの動きの情報を生かすことができます。たとえば、ユーザがよく見るところに人気商品のリンクを設置したりできます。広告とアナリティクスが果たす役割は似ています。
損失を出した失敗談
A/Bテストは、たとえば90％は現状のものを残して、10％だけは変更するといった仕様変更のときに行われます。変更した部分に対してプラス効果があったら、そちらに移行します。QAのメンバーは、こういう要件が入ってきたときに、ほとんど話し合いに参加しません。
4年前に、とあるクーポンページのリリースに携わっていたときのことです。一部の仕様が変更されることになりましたが、QAは誰一人このことを知りませんでした。知らないままでA/Bテストが実施され、機能がリリースされた後で、なんと最も人気のないクーポンが一番上に表示されてしまったのです。原因はそのクーポンのインデックスがゼロにリセットされてしまっていたことでした。インデックスが少ないクーポンが上に表示される仕様について、アナリティクス側は認識していませんでした。
結果として、私たちは大変な損失を出してしまったのです。一番人気のないクーポンを、最もユーザの目につく一番上に表示してしまったのですから。それからというもの、私はアナリティクスに自分から関わるようになりました。
QAとアナリティクス
この問題は、開発プロセスにおいて、QAが上流工程から切り離されていることから起こります。通常、マーケティングで得たデータを元にビジネス戦略が決まり、その施策を実現するソフトウェアを開発するため、プロダクトマネージャ主導のもとで、開発者とQAが実装とテストを行います。開発者とQAには経験の浅い人材がアサインされることが多いこともあって、なかなかそのソフトウェアが何のために開発されているのかまで意識することができません。
そうした構造的な問題はありますが、品質を向上し、損失や信用の失墜を防ぐために、もっとQAが活躍できる場があるはずです。自分の会社がどのようにアナリティクスを活用しているかを知り、関わっていくようにしてください。QAがアナリティクスに入っていくことは、業界にとっても大事なことです。
アナリティクスに役立つツール
BrowserMob Proxy というオープンソースプロジェクトがあります。Seleniumと親和性が高く、トラフィックを監視し、やり取りされるデータが適切であるか、リンクは壊れていないかといったことをテストできます。
TestNG などのツールでテストを行い、Kibana で集計すれば、テスト結果が表示されます。テスト対象のWebサイトの品質がわかるのです。
また、Anand Bagmar は以前Seleniumのカンファレンスで、WAAT(Web Analytics Automation Testing) というツールについて発表していました。極めて簡単にアナリティクスのテストができるようでした。
Manoj Kumar ―コンテナを使ったテスト（Testing Inside Containers） Automated testing in the age of container cluster
この日3人目のコミッターであるManoj Kumar氏は、docker-seleniumなど数々のライブラリ開発に携わってきた方で、ブログAssert Selenium での情報発信も精力的に行っています。
Manoj Kumar氏
継続的デリバリーとテスト自動化
技術をめぐる世の中の要求や環境は、大きく変わり続けています。製品やリリースを可能な限り早く行うことと厳しいコスト最適化の圧力がかかる中で、DevOpsなどの浸透によるパラダイムシフトが常に起こっていますし、コンテナやクラウドコンピューティングを活用した分散コンピューティングが注目されています。
こうした状況で必要とされるのが、継続的デリバリー（Continuous Delivery）という考え方です。継続的デリバリーというのは、継続的インテグレーションと継続的テストがあって初めて可能となるものです。継続的にテストを実施するためには、テストの自動化が必須です。テスト自動化のツールとしてSeleniumがあります。たとえば、Selenium Gridはハブとノードの構成になっていて、マスタ・スレーブ関係でテストを実行します。
継続的テストの課題とDocker
テストを常に書いていくと、テスト全体の量が増え、また実行時間が長くなってきます。そこで、実行時間短縮のため、並行してテストを実施することが求められます。ただ、そのためにはもっとリソースが必要になり、コスト削減の要求に応えることができなくなってきます。並列化によく使われるVM（Virtual Machine）はハードウェアのシミュレーションまで行っていたりするので多くのメモリを必要としますし、メンテナンスコストがかかります。
こうした課題に対して、コンテナ、特にDockerが解決策となります。次のような特徴があります。
動作が軽い
前提として必要なアプリやライブラリが全てパッケージされている
モバイルのテストにも使える
docker-selenium
Selenium GridをDocker環境で使えるようにしているのが、docker-selenium です。これはコンパイルされ実行可能となっているソフトウェアであり、次のようなイメージがこちらのサイト に用意されています。
selenium/hub
selenium/node-chrome
selenium/node-firefox
selenium/node-phantomjs
selenium/node-chrome-debug
selenium/node-firefox-debug
Seleniumにはハブとノードが必要です。複数の仮想マシンを使って、何百件ものテストケースを実行していきます。
テストをDocker化する（Dockerize）というのは先進的ではありますが、普及はしていません。ただ、もしDockerのイメージを開いて機能テストが自動で流れたら素晴らしいと思います。Node.jsやJavaで、YAMLを書くことで、それが実現できるのです。
モバイル
スマートフォンなどモバイルアプリの自動テストには、次のDockerイメージを使うことができます。
Appium Docker for Androidは実機で、Docker-Androidはエミュレータで自動テストを行う場合に対応しています。
オーケストレーションツール
コンテナを活用した自動テストを継続するために、オーケストレーションツールを使いましょう。オーケストレーションツールにはいろいろと便利な機能があり、たとえば何らかの理由でダウンしたノードを自動で再起動することができます。
たとえば、Dockerクラスタ管理ツールのKubernetes をDocker-Selenium環境で使えるようにしたKubernetes-docker-selenium というものがあります。またZalenium やaerokube もお勧めします。
Q&A パネルディスカッション
会場からリアルタイムで集められた質問のうち、多くの票を獲得しているものについて、3人のコミッターが答えていく方式で進んでいきました。
質問に答える3名のコミッター
SeleniumプロジェクトとAppiumプロジェクトは統合する予定はあるのですか？
SeleniumとAppiumは、自動化する対象が異なるプロジェクトであり、統合の予定はありません。
テスト対象が、確率的に振る舞うものや、機械学習で結果が変わっていくものなどのとき、どのようにすればテストを生産性高く行えるでしょうか？
おもしろい質問ですね。機械学習に対するテストというところにたいへん興味がありますが、難しいですね。ソフトウェアテストとマシンラーニング。エンジニアリングとしてはとても面白そうですね。
ヘッドレスブラウザが登場した時はどう思いましたか？また、皆さんは使っていますか？
こういった質問に対しては、いつも逆に、なぜヘッドレスブラウザを使うのかを聞きたいですね。速いからだという人もいますが、実際のところ速くはありません。また、自分がユーザとしてそのWebサイトにアクセスするのに、ヘッドレスブラウザを使いますか？ 使わないでしょう。
ただ、FirefoxやChromeのヘッドレスモードで、通常のブラウザと同じ振る舞いであれば使える場面もあるかもしれませんが、あまり意味はないと思います。ブラウザレベルでテスト自動化をするのは、実際にブラウザを通して表示することでそのWebサイトが安全であるかを確かめられるからであり、また、その画面を自分の目で見ることができるからです。
Selenium IDEとSelenium Builderの今後の動向はどのようになっているでしょうか？
こうしたプレイバックツールは、テクノロジーとしては古いと思います。残念ながら、Seleniumはボランティア活動であり、プロジェクトチームとしてはあまりこうしたテクノロジーには興味がありません。便利だとは思いますが、維持しようという動きはないのが実情です。
ただ、Selenium IDEのようなレコード・プレイバックツールがきっかけになって、Seleniumがさまざまな人に使われるようになってきたというのも事実ではあります。今後、レコード・プレイバックツールに貢献してくれる人が出てくると良いですね。
画面の「見た目」のテストについて、有効なソリューションや、今後どうなっていくかについてお聞かせください。今はDOMの計算済みスタイルや画面のスクリーンショットをスナップショットとして保存し、正解として使うアプローチがあると思います。
画面の見た目のテストで難しいのは、この比較がファジー（曖昧）でよいところはファジーな状態で通して、正確であるべきところは正確であるかを見なければならない、というところですね。
いろいろな企業が（Seleniumを利用したサービスに）参入してきていて、適切なスクリーンショットを提供すると、スナップショットをとって比較できるツールもあります。Seleniumはスクリーンショットに課題があります。ドライバーによっては現在表示している領域だけのスクリーンショットを取るものもありますし、フルページで表示してくれるものもあります。また、フルページという概念が、今はどんどん意義を失ってきていると思います。たとえば、Twitter とか無限にスクロールできますよね。
こうしたあたりもW3Cで標準化していますので、フルページという実装についても、今後W3Cに従ってコードを変更するということになるわけです。
スポンサーセッション・公募セッション
また、今回の勉強会では、3本のスポンサーセッションと1本の公募セッションもありました。
Toshiya Komoda（DeNA）―E2E自動テストの長期運用に耐えるための5つの手法（Five methods to sustain long-term operations of E2E auto test）
Toshiya Komoda氏
株式会社ディー・エヌ・エー のスポンサーセッションでは、ゲームを自分たちで作るというミッションを達成するために、いかに自動テストが活用できる状態を長く保つか、そのためにはどうしたら良いかが紹介されました。
KazuCocoa（Cookpad）―Let's step into the OSS community
KazuCocoa氏
クックパッド株式会社 のスポンサーセッションでは、会社としてオープンソースコミュニティへの貢献を推奨しているということで、これまでにどういう貢献をしてきたかが発表されました。
Tomotaka Asagi（Human Crest）― 継続的E2Eテスト（Continuous E2E Testing）
Tomotaka Asagi氏
株式会社ヒューマンクレスト のスポンサーセッションは、自動テストを継続することの難しさに焦点を当てた発表で、その中でも最大の要因である「担当者がいなくなること」の対策として、Lynx が紹介されました。
Kenichiro Ota（SHIFT）―Windows Application DriverでWindowsアプリも自動テスト^_^ （Automate Windows app test with Windows Application Driver）
Kenichiro Ota氏
Selenium・Appium互換のコードでWindowsアプリのテスト自動化が行えるWindows Application Driver がデモと共に紹介されました。
海外からコミッターを招いて英語で発表が行われるという初の試みでしたが、参加者がたいへん多く、とても活気のある会となりました。当日はTwitterのハッシュタグ「#seleniumjp 」が付いたツイートも活発でした。こちらのTogetter にまとめられています。今回のセッションはSeleniumがオープンソースプロジェクトであることから、Software Freedom Conservancy について触れられたり、またオープンソースにもっと貢献しようという議論が多かったのが印象的でした。
Seleniumを利用したテスト自動化のニーズは日を追うごとに増していて、奇しくもこの勉強会が行われた2017年7月1日は、日本Seleniumユーザーコミュニティ4周年の記念日ということでした。熱心なコミッターや利用者が増え、さらなる進化を重ねるSeleniumは、今後もしばらくブラウザテスト自動化の最有力候補として注目され続けるでしょう。
