Audit Ekstensi Browser Tim untuk Uji E2E Pasca-Manifest V3

Audit ekstensi browser tim untuk uji E2E pasca-Manifest V3 perlu dilakukan sebelum pipeline test mulai gagal secara acak, screenshot visual berubah tanpa sebab jelas, atau reproduksi bug hanya berhasil di laptop tertentu. Intinya sederhana: jika workflow development, QA, atau automation Anda bergantung pada ekstensi browser, maka perubahan model ekstensi di Chrome dan perbedaan perilaku lintas browser bisa menjadi sumber fliksi yang sulit dilacak.

Yang perlu diaudit bukan hanya ekstensi ad blocker. Tim engineering sering mengandalkan ekstensi untuk modifikasi request, inspeksi header, bypass cache, injector script, cookie editor, proxy helper, scraping internal, dan alat bantu accessibility. Begitu ekstensi berubah, dinonaktifkan, atau perilakunya berbeda karena kebijakan browser, dampaknya bisa langsung terasa pada end-to-end testing, visual regression, scraping internal, dan proses debugging.

Mengapa audit ini relevan setelah Manifest V3

Manifest V3 mengubah cara ekstensi browser bekerja, terutama pada area yang sebelumnya leluasa memodifikasi trafik jaringan dan menyuntikkan logika yang agresif ke halaman. Bagi pengguna biasa, ini sering dibahas dalam konteks ad blocker. Namun untuk tim engineering, dampak nyatanya lebih luas: ekstensi yang sebelumnya dipakai untuk mengubah header, memblokir resource, atau mengobservasi request bisa mengalami keterbatasan baru, berubah implementasinya, atau tidak lagi konsisten antar browser.

Masalah utamanya bukan sekadar “ekstensi A masih hidup atau tidak”, tetapi apakah test dan workflow internal Anda diam-diam mengasumsikan keberadaan ekstensi tertentu. Jika iya, test dapat menjadi tidak deterministik karena:

hasil test berbeda antara mesin developer dan CI,
reproduksi bug bergantung pada profil browser lokal,
screenshot visual dipengaruhi CSS/JS yang diubah ekstensi,
request ke environment internal berubah karena header tambahan atau request blocking,
scraping internal gagal karena ekstensi sebelumnya membantu autentikasi, proxy, atau bypass elemen tertentu.

Jenis risiko yang perlu dipetakan

1. Risiko pada E2E test

E2E test idealnya berjalan pada lingkungan yang mendekati pengguna riil atau skenario yang memang Anda definisikan. Ketika browser membawa ekstensi tambahan, perilaku aplikasi bisa berubah tanpa terlihat jelas.

Contoh dampak umum:

popup, banner, atau iframe pihak ketiga hilang karena diblokir ekstensi, sehingga locator test tampak stabil padahal produksi tidak demikian;
request analytics, feature flag, atau consent manager diblokir, sehingga urutan render berbeda;
cookie atau storage dimodifikasi oleh ekstensi, menyebabkan status login tidak konsisten;
header tertentu ditambahkan ke request sehingga backend memberi respons berbeda.

Jika tim Anda pernah mengalami test yang “hanya gagal di CI” atau “hanya lolos di laptop QA tertentu”, ekstensi browser adalah salah satu tersangka pertama yang layak diperiksa.

2. Risiko pada visual regression

Visual regression sangat sensitif terhadap perubahan kecil. Ekstensi yang menyuntikkan CSS, menyembunyikan elemen, mengganti font rendering, memodifikasi iklan, atau menonaktifkan animasi bisa membuat baseline screenshot tidak valid.

Masalah yang sering terjadi:

elemen pihak ketiga tidak muncul pada browser yang memakai blocker,
toolbar atau icon ekstensi mengubah ukuran viewport efektif,
mode gelap atau injector CSS mengubah warna komponen,
resource eksternal diblokir sehingga layout fallback berbeda.

Akibatnya, tim bisa menghabiskan waktu untuk memeriksa diff visual yang sebenarnya bukan berasal dari perubahan aplikasi.

3. Risiko pada scraping internal dan automation non-test

Banyak tim memiliki skrip browser automation untuk admin panel, dashboard internal, portal vendor, atau backoffice yang tidak punya API lengkap. Kadang skrip ini berjalan baik karena browser lokal memiliki ekstensi proxy, cookie manager, user-agent switcher, atau injector token.

Begitu workflow dipindah ke runner yang bersih, perilakunya berubah total. Ini sering terlihat seperti bug pada Playwright atau Puppeteer, padahal akar masalahnya adalah dependensi tidak terdokumentasi pada ekstensi lokal.

4. Risiko pada debugging header dan request

Ekstensi untuk memeriksa atau memodifikasi request memang membantu saat debugging manual. Tetapi jika tim mulai bergantung padanya untuk memahami sistem, maka pengetahuan operasional menjadi sulit dipindahkan ke CI, ke engineer lain, atau ke browser berbeda.

Selain itu, debugging dengan ekstensi sering bercampur dengan state lain di profil browser: cookie lama, service worker, storage, sertifikat lokal, atau pengaturan proxy. Hasil investigasi jadi sulit direproduksi.

Checklist inventaris ekstensi browser tim

Mulailah dari inventaris yang sederhana dan bisa ditindaklanjuti. Target auditnya bukan hanya “apa yang terpasang”, tetapi “apa yang memengaruhi perilaku aplikasi atau test”.

Data yang perlu dikumpulkan

Nama ekstensi dan fungsinya.
Siapa yang memakainya: developer, QA, SRE, data analyst, support engineer.
Browser yang dipakai: Chrome, Chromium, Edge, Firefox, atau lainnya.
Apakah ekstensi wajib untuk pekerjaan tertentu, atau hanya preferensi pribadi.
Apakah ekstensi aktif secara global atau hanya pada domain tertentu.
Apakah ekstensi memodifikasi request, response, header, cookie, localStorage, DOM, CSS, atau network blocking.
Apakah ekstensi memengaruhi login, SSO, proxy, sertifikat, atau akses environment internal.
Apakah workflow automation atau dokumentasi internal menyebut ekstensi tersebut.
Apakah ada alternatif non-ekstensi: proxy lokal, konfigurasi test runner, mock server, atau DevTools.

Klasifikasi yang berguna

Supaya audit tidak berhenti sebagai spreadsheet pasif, kelompokkan ekstensi ke dalam kategori risiko:

Aman/pribadi: password manager, grammar checker, dark mode pribadi, selama tidak memengaruhi aplikasi yang diuji.
Observabilitas: network inspector tambahan, cookie viewer, storage viewer. Biasanya rendah risiko jika hanya membaca.
Modifikasi perilaku: ad blocker, request/header modifier, script injector, CSS injector, proxy helper. Ini kategori paling kritis.
Ketergantungan workflow: ekstensi yang “harus ada” agar login internal, scraping, atau debugging berhasil. Ini perlu dimigrasikan.

Template inventaris yang praktis

Ekstensi: Header Modifier X
Fungsi: Menambahkan header X-Debug-User pada domain staging
Pengguna: QA, Backend, Support
Browser: Chrome, Edge
Aktif di domain: *.staging.internal
Pengaruh: Mengubah request header
Dipakai di automation: Ya, untuk reproduksi impersonation manual
Alternatif non-ekstensi: Tambahkan mekanisme impersonation di backend atau proxy lokal
Tingkat risiko: Tinggi
Status tindak lanjut: Harus dimigrasikan

Cara mereproduksi bug dengan profil browser bersih

Langkah paling murah dan paling sering memberi jawaban adalah mengulang masalah pada profil browser bersih tanpa ekstensi. Ini penting karena banyak bug yang tampak seperti regresi aplikasi ternyata efek samping dari lingkungan browser lokal.

Prinsip dasarnya

Gunakan profil baru, bukan sekadar mode incognito.
Pastikan tidak ada ekstensi aktif.
Hapus state: cookie, localStorage, IndexedDB, cache, dan service worker bila perlu.
Catat perbedaan hasil antara profil harian developer dan profil bersih.

Alur triase yang disarankan

Reproduksi bug pada profil harian seperti biasa.
Ulangi pada profil browser baru tanpa ekstensi.
Jika bug hilang, aktifkan kembali ekstensi satu per satu atau per kategori.
Jika bug tetap ada, bandingkan state jaringan, cookie, dan request header.
Jika hasil masih berbeda, bandingkan environment lain: proxy, VPN, DNS, sertifikat lokal, feature flag, dan akun pengguna.

Pola ini membantu memisahkan bug aplikasi dari bug lingkungan. Dalam banyak kasus, langkah ini lebih cepat daripada langsung menyelam ke kode test.

Catatan: Incognito tidak selalu cukup. Beberapa ekstensi bisa diizinkan berjalan di incognito, dan profil utama tetap membawa konfigurasi lain yang memengaruhi hasil.

Setup Playwright dan Puppeteer tanpa dependensi ekstensi

Tujuan utama migration hardening adalah memastikan automation dapat berjalan tanpa bantuan ekstensi browser. Jika sebuah test atau script hanya sukses ketika ekstensi aktif, maka test tersebut belum portabel.

Prinsip desain test yang lebih stabil

Gunakan API automation untuk network interception, header injection, cookie setup, dan storage state.
Jangan andalkan ekstensi untuk memblokir resource jika test runner bisa melakukannya sendiri.
Simpan autentikasi sebagai state test yang terkontrol, bukan hasil klik manual di browser harian.
Dokumentasikan semua modifikasi trafik yang diperlukan test.

Contoh Playwright: menambahkan header tanpa ekstensi

import { test, expect } from '@playwright/test';

test('akses staging dengan header debug', async ({ browser }) => {
  const context = await browser.newContext({
    extraHTTPHeaders: {
      'X-Debug-User': 'qa-user'
    }
  });

  const page = await context.newPage();
  await page.goto('https://staging.example.internal');
  await expect(page.locator('[data-test-id="dashboard"]')).toBeVisible();

  await context.close();
});

Pendekatan ini lebih baik daripada memakai ekstensi header modifier karena konfigurasi test menjadi eksplisit, bisa ditinjau di code review, dan dapat dijalankan di CI.

Contoh Playwright: memblokir resource tertentu tanpa ad blocker

import { test } from '@playwright/test';

test('jalankan halaman tanpa resource pihak ketiga tertentu', async ({ page }) => {
  await page.route('**/*', async route => {
    const url = route.request().url();

    if (url.includes('third-party-ads.example') || url.includes('tracking.example')) {
      await route.abort();
      return;
    }

    await route.continue();
  });

  await page.goto('https://app.example.com');
});

Ini berguna untuk test terkontrol, tetapi jangan jadikan pemblokiran resource sebagai default jika target Anda adalah perilaku mendekati pengguna nyata. Gunakan hanya untuk skenario yang jelas, misalnya isolasi visual regression atau pengurangan noise dari pihak ketiga yang memang bukan bagian acceptance criteria.

Contoh Puppeteer: browser bersih dan deterministik

import puppeteer from 'puppeteer';

const browser = await puppeteer.launch({
  headless: true,
  args: [
    '--no-first-run',
    '--no-default-browser-check'
  ]
});

const page = await browser.newPage();
await page.setExtraHTTPHeaders({
  'X-Debug-User': 'qa-user'
});

await page.goto('https://staging.example.internal', {
  waitUntil: 'networkidle0'
});

await browser.close();

Intinya bukan sintaks library tertentu, melainkan prinsip bahwa modifikasi perilaku browser harus didefinisikan dalam kode automation, bukan diwariskan dari profil lokal engineer.

Memetakan dependensi ekstensi ke alternatif yang lebih sehat

Kasus 1: Ad blocker dipakai untuk “menstabilkan” test

Ini tanda bahaya. Jika test butuh ad blocker agar stabil, berarti ada sumber ketidakpastian yang belum diatasi dengan benar. Pilihan yang lebih sehat:

mock atau block domain pihak ketiga secara eksplisit di test runner;
pisahkan test acceptance dari test visual yang sensitif terhadap konten pihak ketiga;
gunakan environment yang mematikan integrasi eksternal tertentu melalui konfigurasi aplikasi, bukan ekstensi browser.

Kasus 2: Ekstensi request/header modifier dipakai untuk staging

Lebih baik pindahkan kebutuhan itu ke salah satu jalur berikut:

dukungan header atau token lewat test runner,
proxy lokal yang konfigurasinya terdokumentasi,
fitur impersonation resmi di backend atau admin tools,
endpoint login test yang aman untuk automation.

Keuntungannya: perilaku menjadi dapat diaudit, dapat dipakai lintas browser, dan tidak tersembunyi di UI ekstensi.

Kasus 3: Ekstensi cookie/storage editor dipakai untuk login cepat

Ganti dengan storage state, setup cookie terprogram, atau helper login API jika tersedia. Pendekatan ini biasanya lebih cepat, lebih konsisten, dan lebih mudah dijalankan di CI.

Kasus 4: Ekstensi dipakai untuk scraping internal

Jika scraping internal bergantung pada ekstensi untuk proxy, autentikasi, atau manipulasi halaman, pertimbangkan pemindahan logika ke:

proxy eksplisit di level runtime,
session cookie yang dikelola script,
service account atau jalur API internal,
headless browser dengan routing/interception yang terdefinisi dalam kode.

Membangun matrix CI lintas browser

Jika audit sudah menemukan area rawan, langkah berikutnya adalah memvalidasi bahwa pipeline tidak tergantung pada satu kombinasi browser + profil tertentu. Matrix CI lintas browser membantu menemukan asumsi yang tersembunyi.

Apa yang perlu diuji

Browser berbasis Chromium dan setidaknya satu engine lain bila produk Anda mendukungnya.
Headless dan, jika relevan, mode headed untuk kasus tertentu seperti rendering atau permission flow.
Environment dengan network normal dan environment dengan pembatasan tertentu jika aplikasi internal sering lewat proxy/VPN.
Skenario dengan dan tanpa pemblokiran resource pihak ketiga, jika itu bagian dari strategi test Anda.

Tujuan matrix ini

Bukan untuk menguji semua kombinasi tanpa batas, tetapi untuk menjawab pertanyaan berikut:

Apakah test hanya stabil di Chromium lokal?
Apakah visual baseline hanya valid ketika browser tertentu memblokir resource?
Apakah skrip scraping internal gagal di runner yang bersih?
Apakah login atau impersonation bergantung pada modifikasi header yang tidak ada di CI?

Prinsip implementasi

Mulai dari subset suite yang paling kritis.
Pisahkan smoke test, regression test, dan visual test.
Simpan artefak penting: screenshot, video, trace, log network, dan console.
Bandingkan hasil antar browser, bukan hanya status pass/fail.

Matrix lintas browser sering mempercepat temuan akar masalah karena ia memaksa pipeline berjalan di lingkungan yang tidak mewarisi kebiasaan laptop developer.

Langkah migrasi workflow agar pipeline tetap stabil

1. Bekukan daftar dependensi ekstensi

Tentukan ekstensi mana yang diizinkan hanya untuk produktivitas personal, mana yang berpengaruh ke hasil kerja teknis, dan mana yang harus dihilangkan dari workflow resmi tim.

2. Pindahkan perilaku penting ke kode atau infrastruktur

Jika ekstensi menambah header, blok resource, mengelola cookie, atau menyuntikkan script, pindahkan ke:

konfigurasi Playwright/Puppeteer,
mock server,
reverse proxy lokal,
fitur test harness di aplikasi,
seed data dan helper autentikasi.

3. Standarkan reproduksi bug

Buat prosedur baku: setiap bug browser direproduksi lebih dulu pada profil bersih, lalu dicatat apakah membutuhkan ekstensi, cookie tertentu, atau feature flag tertentu. Ini mengurangi diskusi yang berputar di sekitar “di mesin saya normal”.

4. Tambahkan pemeriksaan ke dokumentasi onboarding

Engineer baru perlu tahu bahwa browser harian mereka bukan lingkungan referensi untuk automation. Dokumentasikan:

cara membuat profil bersih,
cara menjalankan suite tanpa ekstensi,
cara menyalakan logging network,
cara meniru kebutuhan debug tanpa plugin browser.

5. Audit ulang secara berkala

Ekstensi cenderung bertambah diam-diam. Lakukan audit berkala, terutama setelah perubahan kebijakan browser, migrasi tooling test, atau penambahan workflow QA baru.

Kesalahan umum saat melakukan audit

Hanya memeriksa daftar ekstensi, tanpa memeriksa efeknya. Yang penting adalah dampak terhadap request, DOM, storage, dan rendering.
Menganggap CI bersih berarti masalah selesai. Developer lokal masih bisa menghasilkan reproduksi bug yang salah arah jika browser hariannya penuh ekstensi.
Membiarkan ad blocker menjadi bagian implisit dari strategi test. Jika diperlukan, definisikan pemblokiran resource secara eksplisit di runner.
Tidak memisahkan workflow debugging manual dan automation resmi. Alat bantu manual boleh ada, tetapi pipeline tidak boleh bergantung padanya.
Mengabaikan browser selain Chrome/Chromium. Perbedaan implementasi lintas browser sering membuka asumsi yang tersembunyi.

Checklist singkat yang bisa langsung dipakai

Inventaris semua ekstensi yang dipakai developer, QA, dan automation engineer.
Tandai ekstensi yang memodifikasi request, response, DOM, CSS, cookie, atau storage.
Petakan dampaknya ke E2E test, visual regression, scraping internal, dan debugging.
Uji reproduksi bug pada profil browser bersih tanpa ekstensi.
Pindahkan kebutuhan header, cookie, blocking, dan injection ke Playwright/Puppeteer atau proxy yang terdokumentasi.
Bangun subset CI lintas browser untuk mendeteksi dependensi tersembunyi.
Perbarui dokumentasi onboarding dan SOP reproduksi bug.
Audit ulang setelah perubahan besar pada browser, kebijakan ekstensi, atau tooling test.

Penutup

Perubahan ekosistem ekstensi browser adalah pengingat bahwa workflow engineering yang sehat seharusnya tidak bergantung pada kondisi browser lokal yang tidak terdokumentasi. Audit ekstensi browser tim untuk uji E2E pasca-Manifest V3 bukan sekadar respons terhadap perubahan Chrome, tetapi langkah untuk membuat test, visual regression, scraping internal, dan debugging menjadi lebih deterministik.

Jika tim Anda mengandalkan ekstensi untuk membuat test “lebih nyaman”, itu belum tentu masalah. Masalah muncul ketika ekstensi tersebut menjadi bagian tersembunyi dari sistem. Begitu dependensi itu dipetakan dan dipindahkan ke kode, konfigurasi, atau infrastruktur yang bisa diaudit, pipeline biasanya menjadi jauh lebih stabil dan lebih mudah dipelihara.

Quick Search

shopping_cart Keranjang