Agen berhasil mengeklik tombol “Simpan”, lalu melaporkan pekerjaan selesai. Padahal server menolak permintaan, status halaman tetap loading, dan tidak ada draf tersimpan. Klik adalah sebuah tindakan antarmuka; keberhasilan adalah perubahan keadaan yang harus diperiksa.
Browser agent perlu menggabungkan observasi, pemilihan target, tindakan, dan verifikasi. Artikel ini memakai halaman uji sintetis dan API Playwright sebagai contoh. Pembahasannya tidak mengasumsikan semua layanan memberi izin atau antarmuka otomasi yang sama.
Pilih sumber observasi sesuai kebutuhan
DOM dan accessibility tree membantu mengenali label, role, status, serta relasi elemen. Screenshot membantu ketika informasi berada pada canvas, tata letak visual, atau kontrol yang tidak memiliki semantik cukup. Keduanya menjawab pertanyaan berbeda.
Jika tombol memiliki nama aksesibel yang jelas, locator berdasarkan role biasanya lebih mudah dipahami daripada koordinat layar. Jika target hanya tampak sebagai ikon tanpa label, screenshot dapat membantu diagnosis, tetapi solusi produk yang lebih baik mungkin memperbaiki aksesibilitas kontrol tersebut.
Jangan memakai keadaan lama sebagai bukti target masih sama. Navigasi, modal, hasil pencarian, dan pembaruan asinkron dapat mengubah halaman. Ambil observasi baru ketika state berubah sebelum melakukan tindakan berikutnya.
Locator harus menunjuk satu maksud yang jelas
Dokumentasi locator Playwright menekankan locator yang menemukan elemen berdasarkan kondisi saat tindakan dilakukan, termasuk role dan label. Rantai selector yang bergantung pada urutan anak DOM mudah rusak ketika desain berubah.
Contoh halaman memiliki label Judul, tombol Simpan draf, dan region status. Fungsi berikut adalah contoh pengujian untuk halaman lokal yang dikendalikan tim, bukan skrip untuk situs pihak ketiga:
export async function saveDraft(page, title) {
const input = page.getByLabel('Judul', { exact: true });
const button = page.getByRole('button', {
name: 'Simpan draf', exact: true
});
await input.fill(title);
await button.click();
const status = page.getByRole('status').filter({
hasText: 'Draf tersimpan'
});
await status.waitFor({ state: 'visible' });
const savedTitle = await page.getByTestId('saved-title').textContent();
if (savedTitle !== title) {
throw new Error('Judul yang tersimpan tidak sesuai');
}
return { status: 'verified', title: savedTitle };
}Halaman uji harus memastikan elemen saved-title berasal dari hasil penyimpanan, bukan sekadar salinan input saat diketik. Pada sistem nyata, verifikasi yang lebih kuat dapat berupa membuka kembali draf atau membaca identitas serta revisi yang dikembalikan layanan.
Auto-waiting membantu kesiapan elemen, bukan kebenaran bisnis
Playwright auto-waiting memeriksa kondisi seperti elemen terlihat, stabil, dapat menerima event, dan enabled sebelum tindakan tertentu. Pemeriksaan ini mengurangi kebutuhan jeda tetap, tetapi tidak membuktikan proses bisnis berhasil.
Hindari sleep(5000) sebagai penentu selesai. Jeda bisa terlalu pendek saat layanan lambat dan terlalu panjang saat cepat. Tunggu kondisi yang relevan dengan batas waktu yang jelas, lalu tangani kegagalan dengan pesan yang dapat dijelaskan.
Status “Draf tersimpan” juga perlu dikaitkan dengan operasi saat ini. Jika status lama masih terlihat, tes dapat lolos sebelum penyimpanan baru selesai. Gunakan ID operasi, revisi, atau perubahan state yang membedakan hasil baru dari hasil sebelumnya.
Screenshot berguna bila koordinat punya konteks
Saat memakai koordinat, catat ukuran viewport, zoom, scroll, dan konteks modal. Koordinat pada screenshot sebelumnya bisa menunjuk elemen berbeda setelah halaman bergeser. Jangan mengulang klik pada posisi yang sama tanpa observasi baru bila hasil tidak sesuai.
Screenshot dapat memuat data pengguna, tab, atau notifikasi lain. Batasi area yang diperlukan dan simpan artefak dengan akses serta retensi yang sesuai. Untuk pengujian tim, gunakan akun dan data sintetis agar tangkapan layar dapat dibagikan tanpa membawa informasi yang tidak diperlukan.
Untuk kontrol visual yang kompleks, pisahkan identifikasi target dari konfirmasi tindakan. Jika aksi berdampak besar, tampilkan objek konkret yang akan dipengaruhi sebelum mengeksekusinya sesuai kewenangan yang diberikan pengguna.
Verifikasi hasil melalui beberapa lapisan yang relevan
| Lapisan | Contoh bukti | Batasnya |
|---|---|---|
| UI | Status sukses dan judul tampil | Bisa memakai state lokal yang belum persisten |
| Navigasi | Draf memiliki URL atau ID | ID belum tentu menunjukkan isi terbaru |
| Persistensi | Draf dibuka kembali dengan revisi yang benar | Memerlukan akses ke alur baca |
| Efek eksternal | Tujuan menerima objek yang dimaksud | Harus diperiksa sesuai izin dan kemampuan layanan |
Pilih lapisan berdasarkan dampak tugas. Mengubah filter tampilan tidak membutuhkan pembuktian seperti mengirim kampanye. Namun, menyatakan “terkirim” hanya dari tombol yang berubah warna terlalu lemah untuk tindakan distribusi.
Recovery tidak berarti mengulang semua klik
Jika halaman timeout setelah tombol kirim, cari status operasi sebelum mencoba lagi. Pengulangan dapat menggandakan pesanan, pesan, atau publikasi. Simpan checkpoint di alur aplikasi ketika tersedia dan gunakan idempotency key pada layanan yang mendukungnya.
Buat kasus uji untuk label tombol ganda, modal menutupi target, jaringan lambat, status error, hasil lama, dan navigasi ke halaman yang tidak diharapkan. Catat observasi awal, tindakan, serta bukti akhir agar kegagalan dapat direproduksi.
Simpan pula identitas tab dan tujuan navigasi yang diharapkan. Tab dengan judul mirip dapat memuat akun atau lingkungan berbeda. Sebelum tindakan yang mengubah data, cocokkan konteks halaman dengan pekerjaan yang diminta agar verifikasi dilakukan pada objek yang sama.
Untuk tim media, browser agent dapat membantu pekerjaan yang belum memiliki integrasi API, tetapi biaya pemeliharaannya perlu dihitung. Perubahan UI dapat mematahkan alur walaupun kebutuhan bisnis tetap sama. Bandingkan waktu pemulihan serta review dengan biaya pekerjaan utuh sebelum memperluas otomasi.
