※この記事は自分が所属する組織で書いた以下の記事のコピーです。投稿した記事は個人の著作物として自ブログにコピーして良いルールとしています。

https://tech-blog.mitsucari.com/entry/2025/02/17/102259

---

こんにちは、ミツカリCTOの塚本こと、つかびー(@tsukaby0) です。

以下の前回の記事ではDatadog Syntheticを選定する過程の話を主に扱いました。

https://tech-blog.mitsucari.com/entry/2025/02/17/102031

今回の記事では、より具体的な運用の話をしていきたいと思います。

テストケース設計: タイミングと対象環境

前回以下のようなことを考えると良いということを述べました。

• 実行タイミング
  • CI/CDのプロセスでdev, stg等の環境にデプロイした後で実行する
  • prd環境にデプロイする前に実行する
  • prd環境にデプロイした後で実行する
  • 2時間ごとなど、定期的に実行する
• 対象環境
  • 専用の環境を用意しておき、そこで実行する
  • stg環境で実行する
  • prd環境で実行する
• 結果(インシデント)に対する対応プロセス

この点について、ミツカリでは以下のように定めています。

実行タイミング: CI/CDのプロセスでstg環境にデプロイした後で実行する

できるだけ早期に問題を発見したいため、CI/CDの一環として実行することとしました。

対象環境: stg環境

prd環境に対して実行するという考え方もありますし、stgもprdもどちらも対象にするというやり方もあると思います。

stgとprdで二重にテストケースを管理したくないですし、ミニマムに始めたかったのでstg環境だけを対象としました。prdを対象とする場合、変更がデプロイされてからでないとテストできない、というのもあります。問題は早期に発見したいです。(※prd環境でも実行することで問題を早期に(確実に)発見するという考え方もあります。)

結果(インシデント)に対する対応プロセス: CIをGitHub Actionsで構築しているため、E2Eが失敗した場合はCIもFailし、その結果は特定のSlackチャンネルにmention付きで通知する。通知を受けた人(PR mergeしたCI実行者)はE2Eのテスト結果をみて即時対応を開始する

上記の通りです。開発者はlocal環境でテストしてからPRを作りますが、当然十分にテストできていないケースがあります。そのようなケースでSlack通知によって早期に問題に気づけます。

テストケース設計: テスト範囲

テストの方針としては、テスティングトロフィーに従って広く浅く作成する方針としました。同一の画面で分岐がいくつもありえるというケースがあります。例えばcheckboxをcheckしてからButtonを押すケースとcheckしないでButtonを押すケースなどではケースは2つありますが、このような網羅性は求めずにここは1パターンで良いということにしました。

もちろんそのテストしていないケースでバグがある場合、E2Eでは検知できませんが、その画面およびButtonを押すことで発生する副作用が意図通りであるかというテストにはなります。この部分は割り切ってやっています。理想的には網羅性を上げるとバグを減らせると思いますが、残念ながらそこまで作り込んだり保守する体制は今のミツカリでは構築できません。(ミツカリのチーム規模や売上規模が10倍など大きくなった場合はQAチームがE2E環境を保守しつつ、より網羅的にリグレッションテストできる環境を構築すべきだとは思いますが、今やるべきではないと思っています。)

実際の利用者のユースケースを模して、テストケースを作成することにしています。ミツカリ社の製品はtoB向けのミツカリ適性検査です。これはSPIや16Personalitiesをイメージして貰えればと思います。ミツカリのWebアプリケーションの画面には大きく分けて３つのカテゴリがあります。

1. 主に未契約者が閲覧する サービスサイト・LP
2. 導入企業様（主に企業の人事部）が検査の受検者を登録したり、結果を閲覧する 管理画面側
3. 導入企業様の自社の社員など、適性検査を受検する人が利用する 受検画面側

これらに対して以下のようなテストを作成しています。

• サービスサイトTOP(LP)にアクセスし、価格ページと機能ページを閲覧(遷移)し、資料請求ページを開いてから資料請求する。その後入力したメール宛に受付メールが届いていることを確認する
• 管理者が管理画面から適性検査の受検者を登録し、受検を依頼するメールが送られたことを確認する
• 適性検査受検者が適性検査の回答を行う（選択肢を選んで、画面遷移する）、完了ページの表示を確認する

テストケース作成(基本設定)

Datadog Synthetic Monitoring & Testingの画面からテストを作成します。

私が導入した頃は無かったのですが、以下のようにある程度のテンプレートが用意されるようになったようですね。

それらを参考にしてもよいのですが、Start from Scratchを選択します。

対象のURLを選択します。ミツカリの場合はここはstg環境のURLとしています。 ミツカリではstg環境にBasic認証をかけていますが、これを突破することもできます。HTTP Authenticationに必要な値を設定してください。

また、Cookieの設定もできます。例えばログイン後にニュースがポップアップするとか、オンボーディングツールのポップアップが起動してしまい、操作ができないというようなケースがあります。そういう場合は大抵はCookieで完了状態などが管理されているので、ここで完了済みにコントロールできます。その他、特定のCookie値がある場合は特定の挙動をしないなどの開発もできますし、ある程度はコントロールできます。

ここで少し難しいのが、例えばGoogle認証などのOAuth認証しか提供していないシステムの場合です。Google認証のID, PASSを入力させることはできますが、BOTからの操作と判定されて、大抵は先に進みません(reCAPTCHA的なもので防がれる)。これは突破する術がないので、Google認証以外の認証経路を作っておく必要があります。例えばSTG環境でだけ機能する簡易ログインボタンを作るとか、メールアドレスとパスワードによる認証を作るなどです。今の時代の流れ的にはTwitter社のAPI改悪等の影響で、メールアドレスとパスワードの認証経路も用意しておく・登録を促す、というサービスが増えてきている印象があります。

タグについても登録しておくと良いと思います。ミツカリの場合は e2e-tests というタグを付けています。理由は後述します。

次の設定について解説します。

デバイスの選択はお好みで良いと思います。ミツカリではコストダウンおよびE2Eの速度を考慮して Chrome Laptop Large のみ選択しています。近年ではだいぶブラウザ間の差異は無くなってきました。ミツカリの場合はブラウザの違いによる障害や問い合わせはそれほど無いため、このような設定にしてますが、理想的にはより多くのデバイスで検査したいとは思っています。

ロケーションについてもお好みで良いと思ます。ミツカリはグローバル展開していないため、Tokyo (AWS)だけを利用しています。Osakaはあっても良いかもしれませんが、これも前述と同じくコストダウン等の理由から選択していません。

Retry Conditions は重要です。E2Eはどうしても単体テスト等と比較してFlakyになりやすいです。ミツカリでもそのような経験は何度もあります。この問題はRetry Conditionsを設定することで大幅に改善しました。ミツカリでは 1 times に設定しており、失敗した場合でも1回だけ自動でリトライされます。Datadog Synthetic Browser Testはcron的な定期実行もできますが、コマンド実行による即時実行(CIへの組み込み)もできます。その話は後述しますが、定期実行だけでなく、コマンド実行の場合でもこのRetry Conditionsは機能します。

Scheduling & Alert Conditions は見たとおりです。スケジュール設定はミツカリでは不要なため、OFFにしたいのですが、どうやらできないようです。そのため、1weekに設定しています。(ミツカリではCIのプロセスとして実行したいため、定期実行は不要という考えです。)

MonitorについてはDatadogの他の機能と同じですね。詳細は割愛します。これによってE2Eが失敗した場合にSlack通知することもできますが、ミツカリの場合はGitHub Actionsが失敗した場合にそちらのワークフローの1jobとしてSlack通知する仕組みを組んでいるので、このMonitorは使っていません。

ここまでの基本設定を終えたら、次はレコーディングに移ります。

テストケース作成(レコーディング)

レコーディングでは右ペインで実際に画面を操作して、その記録を左に残すことができます。右ペインで操作しづらいときは、Popupして別画面で操作することもできます。

基本的に操作するだけでレコーディングできるため、この点はノーコードでテストケースを作れて楽ですね。非エンジニアやジュニアエンジニアでも十分に作ることができると思います。実際にミツカリにはジュニアエンジニアがいますが、30分程度のレクチャー・キャッチアップだけで、今では普通に保守できています。

画面を操作するだけでは単に画面遷移したりformに入力するだけで終わってしまいます。もちろんこれだけでも意味はあります。デッドリンクを検知できたり、画面が正しく描画できているかなどは検証できます。

それ以外に何かを検証したい場合は適宜Assertionを入れます。

特定の要素が特定のコンテンツ(文字)を持っているか、などは一般的なAssertionですが、メールまでAssertできるのはとても良いですね。

ミツカリでは何かを操作したときにログインユーザーにメールが送られるということがあります。そのようなケースで正しくメールが送られているかを検証するテストを作っています。これを簡単に実現できるのはSaaS型のE2Eツールならではだと思います。

例えば以下のJX通信社のSirosuzumeさんの記事ではPlaywrightとSESとS3を使ってメール配信のテストを行っています。

https://tech.jxpress.net/entry/2024/06/25/142839

これ自体は素晴らしいことですが、ここまで作り込むコストと保守コストがあるという問題があります。

以下のCOUNTERWORKSのkuririmaroさんの記事ではPlaywrightとMailtrapを組み合わせています。

https://zenn.dev/counterworks/articles/d2751f4e5ae2f5

これも開発コストはかかりますし、メールサーバーはmockしていると言えるためprd環境と同じテストにはなりません。

DatadogのMailのAssertionの場合、Datadogがテスト実行ごとに払い出した、Datadog社のテンポラリメールアドレスに対してメールが届いているか？というテストができるため、かなり本番環境に近いテストができるというメリットがあります。

基本的にはこの流れを繰り返してテストケースを作っていくわけですが、毎回作るのは手間なので、Templateというような名称でテストケースを作っておき、そこからコピペして作るとよいかと思います。

テストケースの実行

弊社の場合、GitHub ActionsでCI/CDを構築しています。以下の通り、Datadogが公式にActionを公開しているので、基本的にはこれを利用するだけで良いです。

https://docs.datadoghq.com/ja/continuous_testing/cicd_integrations/github_actions/

先ほどTagとしてe2e-testsを付けると良いと言いましたが、これはCIで実行する対象のテストケースをコントロールするためのものです。上記の記事にもありますが、

test_search_query: 'tag:e2e-tests'

この設定を使って、このタグを付けているものだけを実行できます。中には一時的に実行対象から外したいケースや、定期実行用の別のテストケースがあり、それはCIでは実行したくないなどのケースがあります。タグ管理はそのようなケースで力を発揮します。

運用してみた所感や知見

実際に運用してみて以下のような知見が得られました。

Good

• 2ヶ月に一度程度は本当にバグがあり、E2Eのおかげで早期に問題発見できている
• ミツカリ適性検査の受検画面側は管理画面側と比較してあまり変更が入らないが、それでもライブラリアップデート等の全体変更時に影響はあるかもしれない。その懸念が拭えないため、今までは手動でテストしていた。E2Eを導入してから手動でのテストが大幅に減った (※2020年ごろなどはE2Eを導入しておらず、テストをしなかったため、受検画面側で問題が起きたというケースが若干あったが、近年では同様の問題が発生していない)
• stg環境での動作確認コストをある程度緩和できている
• ある程度安心感を得た状態でprdへデプロイ(リリース)できている
• 低い保守コストでE2Eを運用できている。大きく画面を作り変えた場合などは別として、多少の変更ではテストシナリオを編集(再記録)する必要がない
• ある程度低い金銭コストでE2Eを運用できている。Playwright等の独自実装の方が大幅に安いだろうが、おそらく他社SaaSよりは低コストで運用できている。ちなみにミツカリ社の場合はE2Eだけで年間$3000ほど。

Bad

• E2Eの実行とstgへのデプロイ(CD)を排他制御していないので、PRを連続でmergeした場合などは1つめのPRのE2Eが実行されている最中に2つめのPRの内容がstgにデプロイされてしまい、完璧な状態でE2Eを実行できていない (※とはいえ、2つめのPRのE2Eも動くため、そちらが通れば問題ないとも言える)
• CI/CDにE2Eが組み込まれているせいで、急ぎのリリースの場合でもE2Eの実行(約13分)の待ち時間が発生する。 (※E2Eが通らないとprd環境へのリリースはできないこととしている)
• 対象環境をstgとしているため、並列実行等の制限がある。例えば友人の会社ではdocker-compose + Playwrightで運用しているため、環境を並列で立ち上げることができ、E2Eをパラレル化できるというメリットがあるが、弊社では現状それはできていないし、SaaS型のE2Eではそれはやりづらい
• E2E実行時にスパイクアクセスが発生してしまい、5XX系のエラーが発生してしまうし、stg環境がscale outしてしまう
  • ※この問題はパフォーマンスやリソースの改善で解決したため、直近数カ月は5XXでのFail(Flaky)はほぼ0

今のところ概ね満足していますが、理想的にはもっとランニングコストを下げたいですし、できれば5分未満でE2Eを完了させたいです。また、パラレルで実行したり、よりよいテストケース構成に改善したいとも思っています。このあたりは今後の課題として、折を見て改善していきたいと思っています。

---

今回は運用編ということでDatadog Synthetic Monitoring Browser Testの利用法や運用知見を共有しました。

現在、ミツカリではITエンジニアを募集しています。ミツカリでは製品開発だけでなく、Developer Experienceにも力を入れています。興味のある方はぜひお気軽にご連絡ください！

https://herp.careers/v1/mitsucari