Seleniumの代替としてAutifyでスケーラブルなQA体制を実現。デプロイを1日10回以上に

※ 本内容は英語版からの翻訳です。元記事はこちら

今回のインタビューでは、デジタルマーケティングメディア企業、GoBankingRatesのQAチームにお話を伺いました。クレジットや銀行など、さまざまな業種の顧客にサービスを提供している同社は「よりシンプルなテスト自動化ツールでソフトウェアスタックを検証できないか」と模索していたとのこと。Autifyをトライアル後、テスト体制を変えられる見通しが立ったそうです。

GoBankingRatesはわずか3ヶ月で自動テストの大半をSeleniumからAutifyに移行。これにより、チームを多様化できたと言います。Seleniumのスクリプトを更新する必要がなくなり、シニア開発者は優先順位の高いプロジェクトに集中できるようになりました。さらに、Seleniumのテストスクリプトで不具合が発生した場合、メンテナンスコストが高くなりすぎるという課題にも直面していました。

使いやすいAutifyでQAプロセスを刷新することで、チームを再編でき、ジュニアテスト担当者やインターンを採用してボトルネックが解消されました。Seleniumを使っていたときと比べ、Autify導入後は新しいチームメンバーの研修にかかる時間が劇的に短縮されたそうです。さらに、以前はアメリカのチームが1日8時間しかテストできていませんでしたが、チームにオフショア開発者が加わり、より多くの時間を検証に充てられるようになりました。では、GoBankingRatesはAutifyでどのようにQAチームをスケールし、1日10回以上デプロイするようになったのでしょうか？

GoBankingRatesが直面していた品質保証の課題とテスト自動化の取り組みについて、トリンシー・トーマスさん、ミトゥル・ゴーヘルさん、アンヴィタ・ムナガラさんにお話を伺いました。

― まず、GoBankingRatesの事業について教えてください。

トリンシー: GoBankingRatesは、デジタルマーケティングメディア企業です。アクセス数を増やしたり、コンバージョン率を高めたりするプロダクトを提供しています。当社がサポートしている業種はさまざまです。クレジット業界や銀行業界のほか、幅広い企業と提携してコンバージョンを生み出しています。当社が提供しているアプリケーションはいくつかありますが、例として、WordPressサイトであるGoBankingRates、クレジット関連のお客さま向けのWebアプリ、内部アプリなどが挙げられます。QAチームは、これらのプロダクトの検証を担当しています。

― 皆さんはGoBankingRatesでどのような業務を担当していらっしゃいますか？

トリンシー: 私はQAディレクターです。チームは4～5つありますが、各チームのQAマネージャーがそのチームの品質管理を担当しています。今日は、そのうち2人に来てもらいました。

アンヴィタ: 私はクレジット部門のQAマネージャーを務めています。トリンシーが言ったように、当社はさまざまな業種をサポートしており、そのうちの1つがクレジットです。私はクレジット部門のさまざまなプロダクトの品質管理を監督しています。

ミトゥル: 私は銀行部門のQA全体を監督しています。

― チーム構成や開発サイクルはどうなっていますか？

トリンシー: 最初は、よりフラットな組織構成でした。シニアQAエンジニアが何人かいて、彼らがリードのような役割を果たしていたんです。その後、組織を細分化し、部門ごとにチームを編成しました。チームごとにQA担当者やDevOps、プロダクトマネージャーがおり、各チームでアジャイルセレモニーを行っています。スプリント周期は2週間です。スプリントがあることでチームの速度を把握でき、スプリントが始まると、ストーリーごとに作業を開始していきます。ユーザーストーリーごとに環境が用意されており、当社ではこの環境のことを「ランウェイ」と呼んでいます。1日を通して、またスプリントを通して、何度もデプロイを行っています。スプリントで行うべき作業がすべて終わったら、そのスプリントは完了したことになります。

スケーラブルなオフショアQAチームを構築し、毎日10回以上デプロイするように

― スプリントの途中でも、何度もデプロイしているということですか？

トリンシー: そうです。そのスプリントのなかで、ユーザーストーリーごとに別々にデプロイしています。まず、ユーザーストーリーをランウェイにデプロイして機能テストを行い、その後で回帰テストを実行します。すべて成功した場合はステージング環境にデプロイされ、回帰テストを行います。それもうまくいったら、当社ではプレビュー環境にデプロイしてスモークテストを実行しています。問題がなければ、本番環境に移してスモークテストを行います。それも成功したら、エンドユーザーにリリースされます。つまり、1日に最大10回リリースするチームもあれば、2～3日に1回のチームもあるわけです。

― 1チームが1日10回以上デプロイする場合もあるということは、ほかのチームと合計すると、20回以上デプロイすることもあるのですか？

トリンシー: そうですね。環境ごとにAutifyを使っているわけではありません。チケットに3～4つの環境が加わるため、Autifyの利用回数も増えることになります。

― 驚異的ですね。どのようにしてデプロイ頻度を高めたのか、詳しく伺いたいです。

トリンシー: Seleniumを使っていたとき、複数の並列インスタンスに分けようとしました。環境に応じて、インスタンスを変えていたんです。例えば、ランウェイでは10のインスタンスで、ステージング環境は20くらい。ステージング環境はすべての部門が使っていますから。アプリケーションごとにドメインがあるため、本番環境も10のインスタンスで実行します。

以前はそのようなやり方をしていました。しかし、Autifyを使っている現在は、環境によらず並列インスタンスの数は同じです。そこで、オフショアメンバーを採用し、1日を通してテストを実行できるようにしました。そうすれば、リソースの奪い合いが起きませんから。これは効果絶大でした。Autifyに移行した当初、ピーク時が発生することがありました。全員が同じ時間帯にAutifyを使う必要があったんです。Autifyが使えるようになるのを待たなければならず、ボトルネックになっていました。現在は、時間帯が違うチームメンバーがいますから、この問題を解消できています。

自動テストは、すべてCI/CDパイプラインの一部に

トリンシー: 当社では、アプリケーションごとにリグレッションスイートを用意しています。コンポーネント単位で、小規模なテストスイートがあるのです。自動テストは、すべてCI/CDパイプラインの一部になっています。コンポーネントをもとに、テストプランにマッピングしてあります。タグがデプロイされると、該当するリグレッションスイートが開始するわけです。

以前はこの作業を自動化できなかったのですが、AutifyのAPIを活用することで、回帰テストが成功したか失敗したか把握できるようになり、成功した場合は次の環境に自動的に移して次の回帰テストやスモークテストを開始できるようになりました。

― チームのメンバー構成はどのようになっていますか？QAチームメンバーは何人いらっしゃいますか？

トリンシー: アプリや製品、チームによって異なります。お客さまが直接触れるアプリケーションをサポートするチームもあります。どのチームも対応しなければならない領域は複数ありますし、アプリケーションごとにフロントエンドとバックエンドがありますから、多くのQA担当者が必要です。したがって、開発者1.5人～2人に対してQA担当者が1人という感じですね。データチームの場合、開発者とQA担当者の比率は10：1となっています。全員がバックエンドの作業を行うので、QA担当者はそれほど必要ありません。

フロントエンド（UIベースのアプリケーションなど）については、クロスブラウザテストやクロスデバイステストを行う必要があります。そのため、開発者とQA担当者の比率はプロダクトによって異なります。現在、QA担当者は約15名いると思います。

― 手動テストはしていないのですか？

トリンシー: 手動テストもやっていますよ。受け入れ基準を満たしているかQAチームメンバーが手作業で確認できるように、ユーザーストーリーをはっきりさせることに多くの時間を割いています。手動で検証する際、そのユーザーストーリーの自動スクリプトも構築します。新しい（あるいは最新の）自動テストスクリプトで各ユーザーストーリーの検証を行うわけです。

コードが次の環境にデプロイされると、テストスイートの変更が回帰テストスイートとマージされます。常にフルテストカバレッジを達成できているわけです。

Autifyがあれば、QAはもうボトルネックではない

― Autifyの導入前は、どのような課題がありましたか？

トリンシー: 回帰テストの実行時間が開発プロセスのボトルネックになっていました。回帰テストを完了させるのに5時間程度かかっていたんです。

この課題に対処するため、並列インスタンスを追加し始めました。その結果、実行時間を1時間に短縮できました。ただ、何かが失敗すると回帰テストをやり直さなければならず、さらに1時間かかってしまいます。ほかはうまく行っているのに、1分でも無駄があるのはもったいないと感じていました。この課題を解決したかったのですが、Seleniumで複雑な関数を書くようになったため、迅速に更新できる優秀な人材が必要になりました。チケットがだれに割り当てられたとしても、テストケースをすばやく更新できるべきですが、いつもそのような状態だったわけではなく、優秀な人材を雇い続けるのもお金がかかるので、無理でした。

そこで、チームを再編することにしたのです。リードやマネージャーを置いて、ミッドレベルQAやジュニアQAを採用していく。そして、彼らがSeleniumテストスクリプトの複雑さを取り除けるように、AI型ツールを導入することにしました。

Autify導入を決定する前に、他社の製品も検討しました。目標は、複雑さを減らし、ジュニア～ミッドレベルの人を雇えるようにすることでした。また、回帰テストを確実に実行する必要もありました。Seleniumを使っていたとき、スポットインスタンスを利用していたのですが、実行中にインスタンスが停止してしまうことがありました。レポートが生成される前にインスタンスが停止してしまい、すべてやり直さなければならないこともありました。労力の無駄が多かったわけです。そのため、確実に回帰テストを実行することと、少しでも複雑さを減らすことが当初の目標でした。

Autifyは、複雑さを軽減するために役立ちました。ステップのレコーディングがとても簡単ですし、必要なだけテストケースをいくつでも作れます。最初から一連のプロセスに従うことで、テストケースを作り過ぎてシステムが圧迫してしまうという状況を避けることができました。適切な数のテストケースを構築できています。プロセスさえ守れば、とてもうまくいっていると思います。自己修復も、ある程度頼れます。課題はいくつかありましたが。理由は分かりませんが、実行しているテストケースの数も、種類も以前と同じにもかかわらず、なぜかAutifyのほうが速いんです。SeleniumでもAutifyでも、テストを構築するロジックは同じです。両方ともクラウドサービスを利用していますし。しかし、結局のところ、Autifyのほうがテスト実行が速いのです。

60日かかっていたオンボーディング。Autify導入後は2週間に

― 新メンバーのオンボーディングに時間がかかっていたそうですが、Autify導入によってどのような変化が見られましたか？

トリンシー: 私たちが使っているのはSeleniumだけではありません。ほかにも、CodeseptionというBDDツールやBrowserstackなど、目標達成のためにさまざまなプロダクトを使っています。オンボーディングの際は、アカウントのアクセス権限を付与しなければなりませんし、研修も必要です。最初の1週間は、基礎知識を説明するような感じでした。2週目になってようやく研修が中心になります。慣れてミスなく使えるようになるまで時間がかかったんです。

今はAutifyだけです。オンボーディングは、Autifyについて軽く紹介するだけで終わりです。最初は単純なテストケースを作ってもらいますが、指導もほとんど必要ありません。インターンにも同じことをしてもらいましたが、やはり成功でした。

― 素晴らしいですね。インターンのオンボーディングはどれくらい時間がかかりましたか？

トリンシー: 最初は効果が表れるのに30～60日かかりました。今では1～2週間ほどで同じことを達成できています。

リソースを増やさずに、3ヶ月ですべてのテストケースをAutifyに移行で

― 以前はSeleniumを使っていたそうですが、どのようにAutifyをQAプロセスに導入しましたか？

トリンシー: GoBankingRatesのメインサイトが一番単純なプロダクトなので、そのテストをAutifyで自動化できるか検討しました。すぐにAutifyの可能性が見出せたので、すぐにテスト対象アプリの自動化に取り掛かりました。

同時に、新たなプロセスを整備し始めました。導入前はこれと言って仕組みが整っていなかったので、テストの命名規則などを決めて、メンバーを指導しなければなりませんでした。すべてのテストスイートをAutifyに移行する計画を立てました。3ヶ月かかったと記憶しています。3ヶ月以内にテストケースをすべてAutifyに移行できたんです。移行中は（AutifyとSeleniumを）両方使っていました。大変な作業でしたし、信じがたい話かもしれませんが、リソースを増やさずに達成できました。

― 素晴らしいですね！Autifyでカバーしきれていない部分は、今でもSeleniumスクリプトを使っていらっしゃるのでしょうか？

トリンシー: はい。バックエンドの大変な作業については、Autifyに移行できないものもありました。Package Validation（パッケージの検証）というものがあり、それは今でもSeleniumで使っています。当初は、テストを実行し、結果をどこかに載せて、次のテストスイートがインプットとして結果を拾い、続行するという風にしたかったのですが。対処法が見つかり、うまく行っています。ただ、そのようなテストスイートはSeleniumにあるというだけです。

Autifyで85%のテストカバレッジを達成

― テストカバレッジはどうでしょうか？AutifyとSeleniumでそれぞれどれくらいカバーできていますか？

トリンシー: Seleniumは15～20％くらいです。Autifyのテストカバレッジは80～85%ということになりますね。

― Autifyは80～85％ですか。Autifyにすべて移行する必要はないと思っています。ですが、Autifyで80%以上をカバーでき、オンボーディングの労力も削減できるというのは、非常に大きいですね。

トリンシー: 大部分は独立したアプリケーションとして使っています。QA担当者は両方の技術を理解しなければなりませんから、スキルセットが大切になってきます。専門知識が必要なのはSeleniumで行う「パケットの検証」に関するテストスクリプトだけなので、シニアQA担当者の数は限られていますが、対応できています。テストスクリプトの大半はAutifyに移行してありますから、ミッドレベル・ジュニアQA担当者を雇うようにしたんです。

― シニアQA担当者は複雑なバックエンドの自動化に集中し、ほかのメンバーはAutifyで簡単なパスの自動化に取り組んでいらっしゃる、ということですね。

トリンシー: はい。

機能テストはすべてAutifyでカバー

― WordPressなど、社内アプリケーションがあるとのことですが、Autifyのユースケースとして多いのはどのようなものでしょうか？
また、顧客向けのE2Eテストについても詳しく伺いたいです。顧客のサイトや御社のサイトでコンバージョンを自動化する仕組みがあるかもしれませんね。デプロイのほかにも、Eコマースやマーケティングなどの部門でAutifyが役立つ事例はありますか？

トリンシー: はい。機能テストはすべてカバーできています。WordPressで何かを設定する場合、それを検証するテストケースがあります。どのような設定にしたかによって、それが正しく表示されるか検証できるようになっています。また、提携企業のサイトへのフィードがあるのですが、そのフィードのコンテンツも検証しています。このようなテストケースはエンドツーエンドでカバーできています。クレジットや銀行部門も同様です。

自社の構成システムやアプリケーションはPHPベースのアプリケーションで、そのためのテストスイートもあります。さまざまなロジックのシチュエーションを検証できるようになっています。そのようなケースを検証するには、画面をレコーディングするだけでは無理なので、JavaScriptを挿入する必要があります。とは言え、キャンペーンなどの設定が完了したら、異なるドメインやUIで起動しています。そのためのUIベースのテストスイートがあるのです。

どれもクリックやコンバージョンなどを発生させます。そのようなデータを生成するさまざまなシナリオがあるんです。先ほどお話した「パケットの検証」はそのことです。UIで検証できることは、UIで検証しています。ただ、ネットワークデータだったり、顧客サイトのデータだったりすると、検証できません。そのようなデータは後々、私たちのシステムに戻ってきます。そのため、最終的には、XMLやJSON形式で入ってくる情報をすべて検証しています。パケットから情報を抽出して、検証を行っているんです。あとは検証されたものがデータウェアハウスに戻されます。これらのソースから抽出したデータが、データウェアハウスのデータと一致しているかどうかを検証するスクリプトもあります。

― 顧客のサイトにはアクセスできないので、E2Eテストを行えないとのことですが、コンバージョンの検証は行っているのでしょうか？例えば、顧客サイトで多いデモのリクエスト、見積もり依頼、サインアップなどのコンバージョンは検証していますか？

トリンシー: コンバージョンが何を意味するかというのは状況によって異なります。例えば、あるユーザーが当社のサイトを離れ、顧客サイトに遷移したとします。場合によってはこれがコンバージョンと見なされます。一方、顧客サイトにアクセスしても、サインアップしなければコンバージョンと見なされないこともあります。結局のところ、データなんですよね。コンバージョンがどこで起きたかによって、さまざまな形式でデータが入ってきます。

そのようなシナリオをすべて検証しなければなりません。どこでコンバージョンが起きたかに応じて、適切な検証が行われます。

どこに着地するかスプーフィングして、検証する場合もあります。また、コンバージョンイベントを発火するだけ、ということもあります。すなわち、当社のシステムがイベントを発火するか検証する。それだけでテストが終わることもあるんです。

お客さまから、その日のコンバージョン数やクリック数、インプレッション数を含むファイルを受け取ることもあります。その内容を検証し、こちらで生成したデータと照合しています。

Autifyを導入することで、国際的なQAチームを迅速に構築。より高速で、より多くのタイムゾーンをカバー

― 以前はシナリオ環境のメンテナンス、新メンバーのオンボーディング、チームの拡大など、さまざまな課題を抱えていらっしゃいましたが、Autify導入後はどのような変化が見られましたか？

トリンシー: 短所は1つしかなかったので、まずはそこから。コーディングが大好きな人もいます。コーディングに熱心なメンバーにとって、最大の目標は次のレベルに進むことなんですね。QAメンバーの多くはそれが大きなモチベーションになっています。しかし、Autifyを導入すると、それを彼らから奪ってしまうことになります。以前と比べると、コーディングする必要がほとんどないからです。そのため、Autifyに移行する際、人材を失うことは想定していました。

結局はそうなってしまいましたね。すぐにではありませんが、しばらくすると数人のメンバーが去っていきました。そうなることは分かっていたので、後任としてジュニアメンバーを新たに雇いました。インターンも試し、とてもうまくいきました。だれかを雇って、当社の自動化について教えられると自信があったんです。そうすれば、新メンバーもキャリアを積めますし。

結局、以前より多くのメンバーを雇うことになりました。Autifyに移行中は7～8人だったと思いますが、今ではおよそ20人のメンバーがいます。

より多くの人を雇えましたし、若干のリスクは伴いますが、スキルより成長力を重視して採用するようになりました。成長力があれば、短時間で私たちが望むレベルに育成できるからです。メキシコとインドのメンバーを採用し、幅広い時間帯をカバーできるようになりました。これによってさまざまな効果が得られました。例えば、チケットの対応ができる時間帯が広がりました。アメリカのメンバーがチケットを対応する場合、2日かかります。しかし、そのチケットを海外メンバーに回せば、24時間以内にチケットを解決済みにできるんです。

顧客にしてみれば、チケットを対応するのは海外メンバーでもアメリカのメンバーでも関係ありません。顧客にとって肝心なのは、1日以内に解決できたこと。このように、プロセスを高速化できましたし、採用もしやすくなりました。

― それは大きな変化ですね。対応時間を24時間にすることを意図して海外メンバーを雇ったのでしょうか？

トリンシー: はい。当初、カリフォルニア在住のメンバーを多く採用していました。今では、アメリカ全土、そして世界各国のメンバーがいます。チームの勤務時間が太平洋標準時に縛られなくなりました。チームメンバーが世界中に分散されているので、24時間カバーできるようになったんです。デプロイの時間帯が広がったのは非常に有益です。

プロダクト提供の高速化を目指す

― 次に目指すものは何でしょうか？QAテストに限らず、ソフトウェア開発も含めて、今後の展望をお聞かせください。

トリンシー: 次はスピードアップに取り組みたいですね。すでに高速で提供できていますが、世界の流れはとても速いので、さらに高速化する必要があります。

私たちが気づいたことは、プロダクト提供が遅くなる原因は、環境の間、あるいはワークフローステータスの間の人的要素が大きいということです。例えば、回帰テストが完了して、次の環境にデプロイする準備ができても、だれかが手動でデプロイしなければ次のステップに進みません。

今はその作業を自動化しようとしています。1つは実現できました。Autifyに問い合わせて、APIで解決しようとしています。それができれば、人間が関わらずに1つの環境から次の環境に進められます。失敗したらロールバックできますし、成功したら、人間がOKしなくても、次の環境に進められます。すでにフルカバレッジできていますから。結果も信頼できるので、だれかがチケットを確認しなくてもデプロイできます。

現在利用可能なAPIでも、ステージング環境から本番環境に移せるようになっています。

今後の期待についてですが、Autifyで動的にテストプランを作成できるようになって欲しいですね。そうすれば、ランウェイのより多くの部分を自動化できるはずです。テストプランを動的に作成し、そこにコンポーネントベースのテストケースを取り入れられるようにすれば、QA担当者は機能テストのチケットを受け取れます。機能テストが成功しなかった場合は開発に戻して修正し、質の高いチケットを提供できるわけです。

そのように改善できると思います。チケット間で人が手を出さなければならない場面をできるだけ減らす。今はそのことに注力しています。機能テストをなくすのは不可能ですが、それ以外はすべて自動化できると思います。

― APIによるテストプランの作成、必ず取り組みます！すでにTo-doリストに載っていると思います。うちのメンバーがAPIチケットを担当していますから、近いうちにお届けできるはずです。

アンヴィタ: Autifyはさまざまな機能を実装していて、とてもワクワクしています。実装のスピードも速く、リクエストすると「どれくらいで利用できるようになるかな」と楽しみにしています。とても助かっていますし、感謝しています。

― そう言っていただけて嬉しいです。ありがとうございます！

ミツル: ほかに付け加えることはありません。Autifyはどんどん改善されているので、新機能がリリースされるたびに、ワクワクしながら試していますよ。素晴らしいと思います。

― 良かったです！お客さまの声をもとに改善しているので、皆さんのフィードバックはとても貴重です。ご意見等あれば、私やチームに気軽にお声掛けください。皆さんの開発プロセスを改善するために、尽力していきます！皆さんのお役に立てることを大変うれしく思います。

トリンシー: ありがとうございます！JSスニペットや、テストケースの途中での共有ステップなど、非常にパワフルな機能だと思います。整理するのに効果絶大でしたね。かなり手間を省けましたよ。

― お時間いただき、ありがとうございました。お会いできてよかったです。これからも宜しくお願い致します。

トリンシー: ありがとうございます！