Playwrightによる同意バナーの自動テスト:実践ガイド

同意テストを自動化する理由

手動の同意チェックは、省略されやすく、間違いも起きやすいものです。マーケティングが追加した新しいタグ、テーマの更新、リファクタリングされたスクリプトローダーのせいで、同意前にトラッカーが静かに動き出し、顧客や規制当局が気づくまで誰も気づかない、ということが起こり得ます。ブラウザの自動テストにより、「バナーは今も正しく動作しているか」という問いは、リリースのたびに実行されるものになります。Playwrightは、実際のブラウザを制御し、ネットワークリクエストを傍受でき、新しい独立したブラウザコンテキストを提供してくれるため、適しています。

テストのコンテキスト

各テストは、Cookieもローカルストレージもないクリーンなブラウザコンテキストから始めるべきです。これは初めての訪問者を再現します。ページを使い回すのではなく、テストごとに新しいコンテキストを作成してください。そうしないと、あるテストで保存された選択が次のテストに漏れてしまいます。

テスト1:同意前は何も動かない

ページの読み込み開始の瞬間から、すべてのネットワークリクエストを監視します。ページを読み込み、アイドル状態になるまで待ち、バナーには触れません。その後、リクエストを、分析、広告、ソーシャルピクセルなど、管理しているトラッカーのドメインの一覧と照合します。一覧にあるドメインへのリクエストが一つでもあれば、テストは失敗とします。コンテキストからCookieの一覧も読み取り、必須でないCookieが存在すれば失敗とします。

テスト2:拒否でオフのままになる

  1. 新しいコンテキストでページを読み込む。
  2. バナーの拒否コントロールをクリックする。
  3. 埋め込みメディアのあるページを含め、さらに2、3ページに移動する。
  4. トラッカーへのリクエストがなく、必須でないCookieも設定されていないことをアサートする。
  5. 再読み込みして、バナーが非表示のままで、選択が保持されていることをアサートする。

テスト3:承諾で有効になるべきものが有効になる

承諾をクリックし、たとえば分析リクエストなど、期待されるタグが動作することをアサートします。これは逆の失敗を防ぎます。つまり、同意を記録するのにスクリプトを解放しないバナーで、データと収益を静かに失う原因になります。

テスト4:細分化された選択

設定レイヤーを開き、1つの目的だけを有効にして保存します。その目的に紐づくタグが動作し、他の目的に紐づくタグが動作しないことをアサートします。目的から期待されるドメインへの小さなマッピングファイルを用意しておくと、テストが読みやすく、更新しやすくなります。

テスト5:撤回

承諾し、その後、常設リンクから設定を再度開いて撤回します。以降のトラッカーへのリクエストが止まり、保存された同意状態が変更を反映していることをアサートします。すでに設定されたCookieは明示的に削除する必要がある場合があるため、ポリシーを決めてそれをテストしてください。

テスト6:シグナル

Google Consent Modeを使用している場合は、各選択の前後でページコンテキストのデータレイヤーを読み取り、同意状態の値が一致することをアサートします。デフォルトはdenied、訪問者が承諾したカテゴリはgrantedです。TCF文字列を使用している場合は、TCF APIで読み取り、選択後に存在し、その選択を反映していることをアサートします。

テストの信頼性を保つ

FlexyConsentの活用

FlexyConsentはIAB TCF 2.4、IAB GPP v1.1、Google Consent Mode v2に対応しているため、テストでアサートするシグナルは、ページから読み取れる標準的なものです。バナーは58言語で利用できます。複数の言語に対応している場合は、少なくとも1つの英語以外のバージョンを読み込むテストを含めてください。

重要なポイント

← ブログ すべて読む →