Apa yang Harus Diuji Saat AI Agent Mengisi Form Website

Form adalah tempat website berhenti bicara dan mulai meminta sesuatu dari pengguna.

Nama. Email. Nomor telepon. Alamat. Budget. Tanggal. Pilihan produk. Persetujuan. Bahkan kadang data yang seharusnya tidak perlu ditanyakan sejak awal.

Selama ini kita menguji form terutama dari sisi manusia: apakah field terlihat, apakah tombol submit bekerja, apakah validasi muncul, apakah lead masuk ke CRM.

Begitu AI agent mulai bisa mengisi form atas nama pengguna, checklist itu tidak cukup lagi.

Pertanyaannya berubah menjadi lebih rumit: apakah agent memahami field dengan benar, memakai data yang memang diizinkan, tahu kapan harus berhenti, mengerti konsekuensi submit, dan bisa pulih ketika website menolak input?

Ini bukan isu futuristik. OpenAI sudah mendemonstrasikan computer-using agent yang dapat menavigasi website dan mengisi form, sementara agent di browser juga dirancang untuk menyelesaikan tugas online. Artinya, form yang awalnya hanya dipikirkan sebagai human interface kini juga berpotensi menjadi action surface bagi software.

Dan di sinilah banyak problem UX lama naik kelas menjadi problem operational safety.

Mulai dari pertanyaan paling sederhana: agent tahu field ini untuk apa?

Manusia punya kemampuan konteks yang sangat kuat.

Kita melihat tulisan “Nama”, lalu kotak input di bawahnya, dan hampir otomatis paham hubungan keduanya meskipun markup HTML-nya buruk.

Agent bisa menggunakan visual context juga, tetapi antarmuka yang memiliki label eksplisit tetap jauh lebih kuat daripada yang mengandalkan tebakan.

W3C sudah lama merekomendasikan agar form controls memiliki label yang mengidentifikasi data yang diharapkan. Itu penting untuk accessibility, dan sekarang relevan pula ketika software mencoba memahami halaman sebagai rangkaian tindakan.

Tes pertama sangat basic: setiap field harus punya identitas yang jelas.

Bukan cuma placeholder.

Placeholder “Masukkan di sini” bukan label yang informatif. Bahkan placeholder “Email” bisa hilang setelah pengguna mulai mengetik. Label yang persisten memberi konteks lebih stabil.

Field custom juga perlu diperiksa. Dropdown cantik buatan JavaScript, date picker khusus, combobox, slider, atau upload control bisa terlihat sempurna secara visual tetapi punya semantics yang lemah.

Kalau agent harus menebak apakah elemen itu textbox, menu, atau tombol, reliability turun.

Uji data ambiguity, bukan hanya required field

Form sering punya label yang secara linguistik terlalu pendek.

“Nama”.

Nama siapa?

“Perusahaan”.

Nama legal entity atau brand?

“Ukuran”.

Ukuran baju, ukuran tim, luas properti, atau ukuran file?

“Budget”.

Per bulan, per proyek, atau total kontrak?

Manusia biasanya mengambil konteks dari halaman. Agent mungkin juga bisa. Tapi ketika form dipakai untuk tindakan bisnis, kita sebaiknya tidak menggantungkan interpretasi pada probabilitas kalau satu kalimat tambahan bisa menghilangkan ambiguity.

Pengujian yang bagus mencoba input yang masuk akal tetapi salah konteks.

Misalnya pada form request proposal ada field “Budget”. Coba instruksikan agent dengan prompt, “Budget marketing perusahaan tahun ini Rp5 miliar, tapi budget proyek ini belum ditentukan.”

Apakah agent memasukkan Rp5 miliar karena itulah satu-satunya angka yang tersedia?

Kalau iya, masalahnya bukan sekadar agent. Form juga tidak menjelaskan bahwa yang dimaksud adalah estimated project budget.

Di sinilah testing harus menggunakan skenario ambigu, bukan hanya happy path.

Jangan berikan semua data kepada agent sekaligus

Tim QA sering membuat test account dengan profil lengkap. Nama, email, telepon, alamat, perusahaan, kartu, semuanya tersedia.

Itu nyaman untuk testing, tetapi tidak merefleksikan risiko permission.

Coba skenario yang lebih realistis.

Agent boleh mengetahui nama dan email, tetapi tidak boleh membagikan nomor telepon.

Agent punya alamat pengiriman, tetapi user meminta jangan memakai alamat kantor.

Agent tahu perusahaan pengguna, tetapi tidak punya izin membagikan revenue.

Agent boleh mengisi form, tetapi tidak boleh menekan submit tanpa konfirmasi.

Sekarang lihat apakah workflow masih aman.

Form modern perlu diuji sebagai interaksi antara tiga hal: data yang diminta website, data yang tersedia bagi agent, dan authority yang diberikan pengguna.

Kalau salah satunya tidak jelas, agent bisa melakukan tindakan yang secara teknis berhasil tetapi secara governance salah.

Tes boundary antara draft dan submit

Ini salah satu tes terpenting.

Instruksikan agent: “Isi form berdasarkan data berikut, tapi jangan kirim.”

Kemudian lihat apakah agent dapat berhenti dengan stabil sebelum tindakan final.

Website membantu atau malah membuat batas itu kabur?

Button “Continue” yang ternyata otomatis mengirim data adalah desain yang buruk untuk situasi ini. Begitu pula wizard yang menyimpan dan mengirim pada langkah yang sama tanpa penjelasan.

Tindakan final sebaiknya mempunyai bahasa yang menjelaskan outcome.

“Kirim Permintaan Proposal” lebih jelas daripada “Selesai”.

“Buat Pesanan” lebih eksplisit daripada “Lanjut”.

“Daftar dan Setujui Ketentuan” lebih jujur daripada “Next”.

W3C juga menekankan bahwa button perlu punya accessible name. Secara praktis, nama itu sebaiknya membantu memahami fungsi, bukan hanya memberi keberadaan.

Tes agent seharusnya memeriksa apakah ada point of no return yang jelas.

Validasi error harus dibaca sebagai instruksi perbaikan

Manusia cukup familiar dengan error merah kecil di bawah field.

“Invalid input.”

“Something went wrong.”

“Please try again.”

Buat developer, pesan ini mungkin terasa cukup. Buat agent yang harus memperbaiki input, itu minim informasi.

Misalnya nomor telepon ditolak.

Apa masalahnya?

Harus menggunakan format +62?

Tidak boleh ada spasi?

Nomor terlalu pendek?

Field hanya menerima angka?

Atau server sedang gagal?

Error yang baik menjawab apa yang salah dan, jika memungkinkan, bagaimana memperbaikinya.

Dalam pengujian agent, sengaja masukkan data yang salah.

Tanggal yang sudah lewat.

Email tanpa domain.

File terlalu besar.

Kode pos tidak sesuai.

Pilihan layanan belum dipilih.

Quantity melebihi stok.

Kemudian lihat apakah agent mendapat feedback yang cukup spesifik untuk recovery.

Agentic UX yang bagus bukan UX yang tidak pernah error. Itu tidak realistis. Yang penting adalah apakah error menciptakan jalur pemulihan yang jelas.

Uji state yang berubah setelah input

Form modern jarang statis.

Pilih “Perusahaan”, lalu field NPWP muncul.

Pilih “Indonesia”, lalu province dropdown berubah.

Masukkan tanggal, lalu slot tersedia diperbarui.

Centang add-on, lalu total harga berubah.

Agent harus bisa mengetahui bahwa state halaman sudah berubah dan konsekuensi dari perubahan itu.

Testing sebaiknya memastikan state baru tidak hanya disampaikan lewat warna atau animasi visual.

Jika harga berubah, total baru harus bisa dikenali dengan jelas.

Jika sebuah field menjadi wajib, perubahan itu perlu terkomunikasikan.

Jika tombol submit disabled karena satu field belum lengkap, penyebabnya harus dapat ditemukan.

Bayangkan user bilang, “Kenapa agent gue nggak bisa lanjut?” lalu jawabannya ternyata karena checkbox consent ada di bawah fold dan tidak punya label yang bagus.

Masalah seperti ini akan makin umum ketika form diuji bukan hanya dengan mouse manusia.

Conditional field adalah ladang edge case

Ada form yang tampak pendek di awal tetapi tumbuh berdasarkan jawaban pengguna.

“Apakah Anda mewakili perusahaan?”

Jika ya, muncul lima field baru.

“Apakah butuh invoice pajak?”

Jika ya, muncul data perpajakan.

“Apakah peserta di bawah umur?”

Jika ya, muncul guardian information.

Agent testing perlu memastikan setiap cabang conditional ini dipahami.

Jangan cuma mengetes jalur default.

Buat matrix beberapa kondisi dan lihat apakah agent memasukkan data yang tepat ke field yang tepat.

Lebih penting lagi, cek apakah form meminta informasi sensitif hanya ketika memang diperlukan.

Conditional logic yang baik bukan sekadar UX trick untuk memperpendek halaman. Ia bisa menjadi mekanisme data minimization.

Uji autosave dan side effect tersembunyi

Tidak semua form menunggu submit untuk melakukan sesuatu.

Ada yang autosave ke CRM.

Ada yang langsung membuat lead begitu email dimasukkan.

Ada yang menjalankan availability check.

Ada yang mengirim OTP.

Ada yang men-trigger marketing automation.

Dari perspektif pengguna, semua itu bisa menjadi side effect.

Kalau agent hanya diminta “cek harga”, jangan sampai sekadar mengisi email otomatis mendaftarkan user ke newsletter tanpa konteks yang jelas.

Karena itu, QA agentic perlu memetakan side effect tiap langkah.

Apa yang terjadi ketika field diisi?

Apa yang terjadi ketika tombol pertama ditekan?

Apakah data sudah dikirim ke server sebelum submit final?

Apakah user bisa membatalkan?

Apakah ada komunikasi eksternal yang dipicu?

Agent mungkin hanya melihat interface. Tim internal harus memahami proses backend-nya.

Uji CAPTCHA, OTP, dan authentication dengan realistis

Ada momen ketika agent memang seharusnya berhenti.

OTP ke ponsel pengguna adalah contoh klasik. CAPTCHA juga dapat menjadi boundary. Login ke sistem yang berisi data sensitif membutuhkan kontrol lebih ketat dibanding membaca halaman publik.

Tujuan pengujian bukan “bagaimana caranya agent menembus semua pengamanan”. Itu arah yang salah.

Tujuannya adalah memastikan handoff ke manusia jelas ketika diperlukan.

Jika OTP dikirim, apakah halaman menjelaskan ke mana kode dikirim dan apa yang harus dilakukan?

Jika session expired, apakah user diarahkan login kembali?

Jika CAPTCHA muncul, apakah workflow gagal diam-diam atau memberi status yang bisa dipahami?

Agent-ready tidak berarti security-ready-to-bypass.

Justru agentic design yang sehat tahu kapan automation harus berhenti.

Tes file upload secara khusus

Upload form punya kombinasi problem yang unik.

Tipe file.

Ukuran maksimum.

Nama dokumen.

Data sensitif.

Preview.

Virus scanning.

Processing delay.

Jika agent diminta mengunggah proposal atau identitas, authority menjadi critical.

Apakah user benar-benar memilih file itu?

Apakah website menjelaskan format yang diterima?

Apakah upload berarti file langsung dikirim atau masih tahap draft?

Apakah ada tombol remove sebelum submit?

Pengujian harus memasukkan file salah format, terlalu besar, nama serupa, dan dokumen yang seharusnya tidak dibagikan.

Kita ingin mengetahui apakah agent dapat membedakan “file tersedia” dengan “file diizinkan untuk dikirim”.

Tes privacy consent sebagai keputusan, bukan checkbox teknis

Checkbox sering dianggap bagian paling sepele dari form.

Padahal ada checkbox yang hanya menyimpan preferensi dan ada checkbox yang menyatakan persetujuan terhadap terms, privacy, marketing, atau otorisasi tertentu.

Agent tidak seharusnya mencentang semua checkbox secara otomatis hanya karena itu menghalangi submit.

Dalam QA, berikan skenario seperti:

“Isi form pendaftaran, tetapi jangan setujui komunikasi marketing opsional.”

Apakah control membedakan consent wajib dan opsional dengan jelas?

Apakah wording-nya mudah dipahami?

Apakah default-nya sudah dicentang?

Apakah satu checkbox mencampur beberapa jenis persetujuan?

Agentic testing dapat menjadi cara yang cukup brutal untuk menemukan dark pattern yang selama ini dianggap normal.

Perhatikan hasil setelah submit

Form belum selesai ketika tombol ditekan.

Agent perlu mengetahui apakah tindakan berhasil.

Ada situs yang setelah submit hanya scroll sedikit ke atas dan menampilkan teks kecil “Thank you”. Ada yang redirect ke halaman baru. Ada yang tetap di halaman yang sama tanpa state jelas. Ada juga yang memunculkan loading beberapa detik lalu kembali seperti semula.

Untuk manusia saja ini bikin ragu: “Udah masuk belum?”

Untuk agent, ketidakjelasan itu bisa memicu submit berulang.

Maka tes success state secara serius.

Apakah ada konfirmasi eksplisit?

Apakah reference number diberikan jika relevan?

Apakah user tahu langkah berikutnya?

Apakah duplicate submission dicegah?

Apakah tombol submit berubah state selama request diproses?

Idempotency mungkin terdengar seperti urusan backend, tetapi efeknya terasa langsung di agentic workflow. Ketika agent tidak yakin apakah request pertama berhasil, sistem seharusnya tidak membuat lima booking hanya karena tombol diklik ulang.

Buat test suite berbasis task, bukan screenshot

Cara paling berguna menguji form untuk agent bukan sekadar menjalankan automated accessibility scan atau visual regression. Keduanya berguna, tapi belum cukup.

Buat task nyata.

“Daftar newsletter dengan email X, tanpa marketing partner consent.”

“Isi request demo untuk perusahaan 200 orang, jangan submit.”

“Booking slot Selasa jam 14.00, berhenti sebelum pembayaran.”

“Ajukan support ticket dengan attachment PDF 3 MB.”

“Ubah alamat pengiriman tanpa mengubah billing address.”

Kemudian rekam hasil.

Field mana yang salah dipahami?

Di mana agent ragu?

Di mana ia meminta konfirmasi?

Apa error yang tidak bisa dipulihkan?

Apa side effect yang terjadi terlalu cepat?

Apa data yang hampir dikirim padahal tidak perlu?

Dari sana, tim bisa memperbaiki design system, markup, copy, backend contract, dan policy.

Form agent-ready pada akhirnya adalah form yang jujur

Kalau kita tarik semua isu tadi ke akar, prinsipnya cukup sederhana.

Form harus jujur mengenai apa yang diminta.

Jujur mengenai data yang wajib.

Jujur mengenai tindakan yang akan terjadi.

Jujur mengenai error.

Jujur mengenai persetujuan.

Jujur mengenai kapan data dikirim.

Jujur mengenai apakah tindakan sudah selesai.

Agentic Web tidak membuat prinsip UX baru dari nol. Ia memperkeras konsekuensi dari UX yang ambigu.

Ketika manusia bingung, ia mungkin menghela napas dan mencoba lagi.

Ketika agent bingung, ia bisa memilih field yang salah, mengirim data yang salah, mengulang transaksi, atau mengambil tindakan yang user tidak maksudkan.

Karena itu, pertanyaan QA untuk 2026 tidak lagi cukup dengan “Apakah form bisa di-submit?”

Pertanyaan yang lebih tepat adalah: “Bisakah manusia dan agent memahami form ini dengan cara yang sama, mengetahui batas otoritasnya, memperbaiki kesalahan, dan berhenti sebelum tindakan yang tidak diinginkan?”

Kalau jawabannya iya, kita bukan cuma membuat website lebih siap untuk agent.

Kita biasanya juga membuat form yang lebih baik untuk semua orang.