on test

HAROiD プラットフォームの UI テストの話

しょくぶつ

はじめまして。HAROiD のしょくぶつがかり兼エンジニアの @naoiwata です。 オフィスを快適環境にすべく、日々しょくぶつ達の水やりに励んでいます(※1)。

しょくぶつは手入れして管理しなければダメになってしまうように、サービスも生き物です。 不具合を修正したり機能追加など手を入れながら、プラットフォームチームでは、去年リリースしたばかりの HAROiD プラットフォームを育てているところです。

今回は保守について、担当で進めている UI のテストについて書いてみようと思います。

プラットフォームチームのテスト体制

下図がチーム開発時のテストの流れになっています。

テスト運用

HAROiD プラットフォームは、プラットフォームサービス、プロジェクトサービス、Bridge サービス、リアルタイムログサービス、JavaScript SDK など、様々なサービスから構成されています(※2)。
基本的にはひとつのサービスをアサインされたエンジニアが担当して設計、開発、テストを行なっています。
設計は必ず複数人でレビューをして、実装しながらテストも書きます。 それぞれのサービスには依存関係がありますが、開発時にはスタブサーバやモックを立てて、自分の担当するサービスの開発の進捗が、他サービスの開発の進捗に依存しないようにしています。

ここまでで言及したテストは「単体テスト」や「受け入れテスト」と呼ばれているものです。個々のサービスやサービス間が、その設計通りに機能しているかを確認するテストですね。
前述したように HAROiD プラットフォームはこれらの複数のサービスが互いに相互作用して初めてひとつのサービスになります。

ここで、これらサービス全体の、新規登録、ログイン、変更、ログアウトして別アカウントでログイン、TV に参加して遊ぶ… などのあらゆる UI の動作確認ができて初めて、サービス全体が設計通り機能すると確認できます。 しかし、手動でこれらのあらゆるテストシナリオを網羅しながら、毎回検証していては数時間以上かかり、人的工数が増えてしまいます。
そこで、サービス全体が設計通りに機能するかの UI テストも実装して自動化しています。

UI テストの概要

UI テストでは、実際のユーザが使うシナリオを想定したテストケースに基いて、実際のデータソースを使った検証を実施し、個々のテストだけでは検証できなかったサービス間の振る舞いや副作用を確認します。

本テストの目的は、サービスがユーザの操作によって期待する結果を得られるよう動作するか確認することです。ユーザの操作によって DB の値がどう変化するとか、API のレスポンスはどんな値になるか、の内部の振る舞いはここではテストしません。あくまで UI の振る舞いだけをテストします。

UI テストの自動化と運用

現在の UI テスト全体図は以下のようになっています。

UI テスト全体構成

Jenkins からテストを開始させて、EC2 内の Web ブラウザ上で数百通り以上のテストシナリオを並行で走らせ、終了すると結果ファイルを指定の S3 Bucket にアップロードし、テストの合否と結果 HTML の URL を Slack で通知するような仕組みにしています。

プラットフォームチームでは、デプロイ後に必ずこの UI テストを実施するようにしています。テスト環境でテストをすべて PASS しないかぎり顧客環境でデプロイはしません。

このように UI テストを自動化することによって、動作検証にかかる人的工数を大幅に削減することができました。また、上記のように仕組み化したことで、

  • 属人化の排除 (チームの誰でもいつでも UI テストを開始し結果を確認できる)
  • テスト実行時間の短縮化 (並列化することで自動テストにかかる時間を 80% 削減)

も実現しました。

終わりに

ここまでで、チームでのテストの取り組みと、その中の UI テストの概要を話しました。今後も更なる改善と品質向上に務めるべく取り組んで参ります。

今後とも HAROiD をよろしくお願いします:D

References