こんにちは。プレイドの野田(@positiveflat)です。 弊社株式会社プレイドでは、ウェブ接客プラットフォームのKARTEというサービスを開発・提供しています。今回は、私たちのチームの開発方針に触れ、その方針を実現するための取り組みの一部として行っている、我々の製品の品質を維持するGUIテストの仕組みについてご紹介いたします。
目次
- プレイドの開発方針とGUIテストの位置付け
- GUIテストの自動化が進むにつれて起こる問題
- CircleCI上でのテストの並列実行による総実行時間の短縮
- CircleCI Enterpriseの導入によるテストの高速化
- Ghost Inspectorを使ったGUIテストスクリプト開発の高速化
- 課題
- 最後に
プレイドの開発方針とGUIテストの位置付け
弊社の開発チームでは、以下の方針のもと、フラットな組織でスピード感のある開発を目指しています。
- 全員が自分で判断する
- 全員がゼロベースで考える
- 全員が成長する
これらの実現のために、あえてマネジメントを置かずに自由でフラットなチーム体制で開発を行っています。
スピードを重視したまま各メンバーが自走するには、失敗を許容し、トライアンドエラーを許容する文化が必要であると考えています。とにかく試してみて、失敗したら考え直します。
一方で、お客様へに安心して使っていただくために、当然品質は担保しなければなりません。KARTEは現在、大企業から中小企業、地方の商店まで、多数のお客様に導入いただいております。
私たちは日々KARTEの新機能の追加や既存機能の改善を行っており、ほぼ毎日本番環境に変更を反映させています。
本番環境に反映させた変更に問題があると、直接お客様の業務に影響を与える可能性があります。また、接客サービスの配信に関わる箇所に関しては、お客様のサイトを閲覧している来訪者にも正しく接客ができなくなる可能性があります。
ユーザーに安定的にサービスを提供し、一方で開発のスピードを高速化するためには、トライアンドエラーのサイクルの中に品質を保証する仕組みを導入していく必要があります。
そこで、我々は重要なシナリオに関してはGUIテストの自動化を行い、正しくアプリケーションの操作が行えることを自動でテストできるような仕組みを作っています。
GUIテストの自動化が進むにつれて起こる問題
日々の開発の中で、追加した変更が生む欠陥をできるだけ早期に発見できるようにするために、リモートブランチに変更がpushされる度にCIツールのプロセスが回り、ユニットテスト（UT）や自動化されたGUIテストが流れるようにしています。
ちなみに、GUIテストはSelenium webdriverを使用してテストスクリプトを書いています。リリース時にはCircleCI上でproduction buildを作成したりもしていますが、これについての説明は本記事の主題と外れるので割愛します。
自動化されたGUIテストを流すことには、以下のようなメリットがあります。
- 人手よりも短時間でテストを実行することができる
- 人手では気が付きにくいバグも発見することができる
- regressionの早期発見ができる
一方で、GUIテストの自動化が進むにつれて、以下のような問題も起きます。
- テストコードが長くなると、テストを流すのに時間がかかり、テスト待ちが起きる
- UIを変更した際に、テストコードのメンテナンスに時間がかかる
弊社では、上記の課題を解決するために、様々な取り組みをしてきましたので、ここからはその取り組みを紹介します。
CircleCI上でのテストの並列実行による総実行時間の短縮
弊社では、上でも触れたように、githubのブランチへのpushごとにCircleCIのプロセスが走るようにしています。その中でGUIテストとUTが流れ、そのブランチを紐付けたPull Request上にテストの結果を表示して、レビュー前に確認できるようにしています。
CircleCIの並列化は、CircleCIの管理画面でコンテナ数を増やした後に、circle.ymlで並列実行したいコマンドに以下のようにオプションを渡すだけで簡単にできます。
test:
override:
[並列実行したいコマンド]:
parallel: true
(参考: https://circleci.com/docs/parallel-manual-setup/ )
CircleCI Enterpriseの導入によるテストの高速化
テストやビルド、デプロイのためのCIツールとして、CircleCI Enterpriseを使用しています。当初はCircleCIのコンテナ数ごとの課金の通常プランを使用していましたが、テストの実行時間に課題がありました。
codeshipやTravis CIなどの他のCIツールも試してみましたが、現在はマシンスペックをコントロールすることができるCircleCI Enterpriseを導入しています。
CircleCI Enterpriseですと、コンテナは独自にインスタンスを立てて管理する必要がありますが、pushが少ない深夜はインスタンス数を減らすなど、独自に工夫して管理しています。
Ghost Inspectorを使ったGUIテストスクリプト開発の高速化
新しい機能が頻繁に追加されたり、既存の機能が頻繁にアップデートされたりすると、更新すべきGUIテストのスクリプトが多くなり、更新が追いつかなくなります。
そこで、Ghost Inspectorというサービスを使い、テストスクリプト作成を簡易化する取り組みにもチャレンジしています。Ghost InspectorはSelenium IDEベースのウェブサービスで、実際の画面操作をレコーディングして、テストケースに落とし込むことができます。
Ghost Inspectorでは、下図のようにChromeの拡張機能を使ってレコーディングをスタートすることができます。
レコーディングしたテストはAPI経由で実行可能なので、CircleCIなどのCIツールからも呼び出すことが可能です。 また、テスト結果はビデオで録画されているため、テストが失敗した場合はどこでテストが失敗したかを確認することができます。
ただし、CircleCIで使用しているインスタンスはプライベートネットワーク上にあるため、Ghost Inspectorからそのままアクセスすることはできません。
通常プランのCircleCIのインスタンスを使用する場合は、ngrokなどを利用してトンネルを掘り、外からアクセスを可能にする方法が便利です。CircleCIから実行する場合のcircle.ymlは、大まかに以下のようになります。
test:
override:
- [環境変数の設定やビルドの設定コマンド];
- [KARTE(テスト対象サービス)の起動コマンド];
background: true
- npm install ngrok -g #ngrokのインストール
- ngrok authtoken <auth_token> #authtokenの設定
- ngrok http -subdomain=<testhostname> 8020;
background: true
- sleep 120
- curl "https://api.ghostinspector.com/v1/suites/<suite name>/execute/?apiKey=<api_key>&startUrl=https://<testhostname>.ngrok.io/" > ghostinspector.json
- if [ $(grep -c '"passing":false' ghostinspector.json) -ne 0 ]; then exit 1; fi
fi
このサービスの便利なところは、レコーディングを使ってテストを追加するGUI操作ができれば誰でもテストを作ることができるようになるところです（ただし、実際はUIの更新の待ち時間の調整など、微調整が必要でした。）。
最終的にはテストコードを書いた方が良い場合でも、新しい機能や変更があった機能に対してGUIのテストをまず早い段階で用意しておくことは、回帰テストとしては有効だと考えられます。
課題
以上のように、プレイドでは攻めの開発方針を実現するために、CIによるテストの自動化など様々なことに取り組んでおります。
しかし、テストカバレッジは今後も上げていかなければならないですし、それと共にテストの実行時間は長くなるので、依然として課題は残ります。レコーディングによるテスト自動化も、レコーディング後に継続的に実行できるように微調整が必要なため、なかなかうまくフローに組み込めないなどの課題もあります。
今後もこれらの課題の解決の解決に取り組みつつ、開発方針を維持できるような仕組みづくりをしていきたいと考えています。
最後に
テスト自動化に関しては、この他にもPCやスマートフォンなどの複数端末上でのテストを自動化し、並列実行する取り組みなども行っていますが、それについても後日このブログで紹介させていただきます。
ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。
詳しくはこちら（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！