Pengujian Agentik - Peran Agen dalam Stack Pengujian E2E

• Tim engineering Slack menjalankan lebih dari 200 workflow agentik untuk memverifikasi apakah pengujian E2E (End-to-End) berbasis agen dapat menggantikan pengujian deterministik konvensional
• Sementara pengujian E2E tradisional memaksakan jalur UI yang telah ditentukan, agen memverifikasi apakah tujuan (goal) tercapai dan dapat mencapai hasil yang sama lewat jalur berbeda
• Eksekusi agen memerlukan $15–30 per run dan lebih dari 10 menit, tetapi jelas memiliki kegunaan dari sisi keandalan
• Pendekatan Playwright MCP mencatat tingkat kegagalan lebih rendah dan penggunaan token lebih sedikit dibanding pendekatan CLI atau pembuatan kode, sehingga stabilitas lingkungan eksekusi sangat menentukan hasil
• Pengujian agentik tidak menggantikan pengujian yang ada, melainkan ditambahkan di puncak test pyramid sebagai lapisan untuk eksplorasi, debugging, dan verifikasi perilaku kompleks

---

Dari Journey ke Goal (From Journeys to Goals)

• Pengujian E2E tradisional memverifikasi journey tertentu yang mengikuti UI → klik → klik → input → assert
• Pengujian berbasis agen memverifikasi apakah goal dapat dicapai yang dinyatakan sebagai instruksi seperti "kirim pesan thread" → goal → agen beradaptasi → verifikasi hasil
  • Perbedaan utamanya: "pengujian memaksakan journey, sedangkan agen memverifikasi goal"
• Seluruh workflow (login → pencarian → hasil → reset) tetap konsisten, tetapi urutan tindakan aktual berubah setiap kali
  • Metode input yang berbeda (klik saran pencarian vs menekan Enter)
  • Pola navigasi yang berbeda (menjalankan ulang pencarian vs memakai status yang ada)
  • Langkah yang ditambahkan atau dihilangkan (klik tambahan, snapshot, tindakan perantara)
• Fleksibilitas ini disertai trade-off dalam keandalan, biaya, dan waktu eksekusi

• Pertanyaan utama

  • Pertanyaan intinya adalah apakah pendekatan yang memerlukan $15–30 per run dan lebih dari 10 menit dapat masuk ke workflow pengujian modern
  • Dari hasil lebih dari 200 eksekusi, pendekatan ini terbukti secara mendasar berbeda dari pengujian tradisional, namun tetap menunjukkan keandalan tinggi dan use case yang jelas
  • Kemajuan large language model (LLM) yang memungkinkan penulisan kode, debugging kegagalan, dan manipulasi UI secara langsung membuka model eksekusi baru ini

Susunan eksperimen (Our Experiment)

• Untuk mengukur keandalan, kecepatan eksekusi, dan biaya, dilakukan lebih dari 200 eksekusi otomatis dalam beberapa konfigurasi

• Model eksekusi (tiga pendekatan)

  • Agent + Playwright MCP: agen berinteraksi dengan browser melalui tindakan browser yang sudah didefinisikan sebelumnya (klik elemen, input, membaca status DOM, dll.) sambil mempertahankan konteks yang persisten (snapshot DOM dan log)
  • Agent + Playwright CLI: menjalankan perintah Playwright CLI di shell untuk memproses satu langkah setiap kali, lalu memutuskan tindakan berikutnya berdasarkan status UI yang diperbarui
  • Generated Playwright Tests: agen AI menghasilkan kode Playwright deterministik dari deskripsi bahasa alami, lalu menjalankannya sebagai pengujian E2E standar dan mengulang perbaikannya hingga lulus

• Lingkungan eksperimen

  • Model agen MCP dan CLI: Claude Sonnet 4.5
  • Model untuk generated Playwright tests: Claude Opus 4.6
  • Eksekusi: Claude Code non-interaktif (claude -p)
  • Alat browser: Playwright MCP, Playwright CLI
  • Lingkungan: Slack Dev API MCP, seluruh eksperimen dijalankan di workspace pengujian dengan data non-produksi

• Alur pengujian (dua tingkat kompleksitas)

  • Thread Reply (sederhana): workflow sekitar 15–20 langkah yang mencakup pembuatan channel, pengiriman pesan, balasan thread, dan verifikasi status thread
  • Search Discovery (kompleksitas menengah): workflow sekitar 25–30 langkah yang mencakup input kueri pencarian, eksplorasi hasil, perpindahan antar-view (pencarian, channel, thread), dan verifikasi hasil yang diharapkan

• Format input

  • Natural language (NL): instruksi yang mudah dibaca manusia, menjelaskan workflow dan hasil yang diharapkan sebagai daftar langkah demi langkah
  • Structured YAML: format terstruktur yang menyatakan workflow yang sama dalam bentuk langkah, tindakan, target, dan hasil yang diharapkan
    • Perbedaannya bukan pada tingkat detail melainkan cara representasi — bahasa alami harus ditafsirkan dan dipetakan oleh agen, sementara YAML mendefinisikan pemetaan itu secara lebih eksplisit

• Matriks eksperimen

  • Setiap konfigurasi dijalankan 20 kali, dengan total 5 eksperimen (MCP-NL, MCP-YAML, CLI-NL, CLI-YAML, generated tests-NL) yang diterapkan pada dua flow: Thread Reply dan Search Discovery

Hasil pengamatan (What We Observed)

• Ringkasan hasil

  • Agent (Playwright MCP): tingkat kegagalan 0% (thread reply) / sekitar 12% (search discovery), rata-rata 5–8 menit
  • Agent (Playwright CLI): tingkat kegagalan sekitar 12% / sekitar 20%, rata-rata 9–11 menit
  • Generated Playwright Tests: tingkat kegagalan sekitar 8% / sekitar 48%, rata-rata 3 menit

• Keandalan (Reliability)

  • Semakin kompleks flow, semakin jelas perubahan keandalannya
  • Playwright MCP paling stabil — hampir 0% kegagalan pada skenario sederhana, dan tetap 0–12% pada flow kompleks
  • Playwright CLI memiliki tingkat kegagalan lebih tinggi (sekitar 12–20%), yang sebagian besar berasal dari masalah eksekusi seperti penanganan autentikasi, timing navigasi, dan ketidakstabilan sesi, bukan dari penalaran model
  • Generated tests cukup baik pada flow sederhana (sekitar 8%), tetapi memburuk tajam pada workflow kompleks (sekitar 48%)
    • Bukan sepenuhnya salah; biasanya tetap berjalan hingga 70–80% flow sebelum gagal pada interaksi atau assert terakhir
    • Penyebab kegagalan adalah variabilitas status UI dan ketidakcocokan abstraksi — test dihasilkan dari flow bahasa alami yang didefinisikan longgar dan menggunakan kembali abstraksi page object yang ada, sehingga menghambat penargetan elemen yang presisi
  • Semakin tinggi kompleksitas, semakin besar kesenjangan keandalan, dan model eksekusi yang native untuk agen seperti MCP lebih stabil
    • MCP mempertahankan tampilan aplikasi yang real-time dan stabil, sedangkan CLI merekonstruksi status dari snapshot setiap langkah → semakin panjang flow, semakin banyak ketidaksesuaian yang menumpuk
    • MCP tampaknya menggunakan kembali interaksi sukses dari langkah sebelumnya dalam satu sesi, sementara CLI terasa seperti memulai ulang dari awal pada setiap langkah (meskipun ini tidak diukur secara eksplisit)

• Kecepatan (Speed)

  • Generated tests secara konsisten paling cepat (sekitar 3 menit), MCP sekitar 5–8 menit, CLI sekitar 9–11 menit
  • Angka generated tests mencakup pembuatan test + eksekusi, dengan setiap test dibuat sekali lalu dijalankan 5 kali sebagai rata-rata
    • Eksekusi murninya jauh lebih cepat — thread reply sekitar 32 detik, search discovery sekitar 45 detik
    • Dalam lingkungan CI yang berjalan berulang, biaya pembuatan satu kali menjadi nyaris dapat diabaikan, sehingga pengujian deterministik dapat diskalakan dengan efisien
  • Workflow agen menimbulkan biaya di setiap eksekusi — setiap langkah melibatkan observasi status UI, inferensi tindakan berikutnya, pelaksanaan tindakan, dan verifikasi hasil

• Adaptabilitas (Adaptability)

  • Hanya sekitar 20% eksekusi yang mengikuti urutan tindakan yang sama, dan sebagian besar menemukan jalur UI valid yang berbeda untuk mencapai goal yang sama
    • Membuka menu dalam urutan berbeda
    • Memilih elemen UI yang sedikit berbeda
    • Menggunakan alur navigasi alternatif
  • Untuk pengukuran, dibandingkan action signature antar-eksekusi — daftar urutan tool call dan tindakan UI yang dilakukan agen
    • Sebelum dibandingkan, dilakukan normalisasi: parameter, tindakan wait/snapshot, dan variasi tool yang ekuivalen (fill vs type) digabungkan agar hanya perbedaan yang bermakna yang dihitung
  • Meski hasil akhirnya benar, urutan tindakannya hampir selalu berbeda — E2E tradisional memaksakan satu journey deterministik, sedangkan agen menjelajahi antarmuka untuk memverifikasi apakah status tujuan tercapai

• Biaya dan sumbernya (Cost and Where It Comes From)

  • Eksekusi agen biasanya memerlukan $15–30 per run, jauh lebih mahal daripada pengujian tradisional
  • Analisis penggunaan token pada flow search discovery yang sama
    • MCP (Opus 4.6) sekitar 3.8M, MCP (Sonnet 4.5) sekitar 3.5M, MCP (Haiku 4.5) sekitar 5.7M
    • CLI (Opus 4.6) sekitar 6M, Code Gen (Opus 4.6) sekitar 7M
  • Yang lebih penting bukan model apa yang dipakai, melainkan bagaimana eksekusinya dilakukan — Haiku memakai lebih banyak token, tetapi semua pendekatan MCP memakai token lebih sedikit daripada CLI dan Code Gen
  • Analisis cara Claude Code mengeksekusi sesi: API dasarnya stateless, sehingga seluruh system prompt dan riwayat percakapan lengkap dikirim ulang di setiap turn
    • Biaya ditentukan bukan oleh output model, melainkan oleh kecepatan akumulasi konteks dan jumlah turn
  • Jumlah turn: MCP (Opus/Sonnet) sekitar 40, MCP (Haiku) sekitar 60, CLI (Opus) sekitar 85, Code Gen (Opus) sekitar 70
    • CLI membagi setiap interaksi browser menjadi banyak perintah seperti aksi, wait, snapshot, read, dan pencarian elemen, sehingga rata-ratanya mencapai 85 turn
    • MCP menggabungkan interaksi dan pengembalian status dalam satu round-trip
    • Setiap turn tambahan menambah biaya system prompt penuh dan beban pengiriman ulang konteks percakapan sebelumnya
  • Faktor yang mengisi konteks
    • MCP dan CLI: snapshot browser adalah payload utama — snapshot accessibility tree yang dikembalikan Playwright MCP menumpuk ke semua turn berikutnya
    • Code Gen: di setiap retry, output test runner yang berisi full error trace, assert failure, dan status DOM ikut menumpuk
  • Sebagian besar biaya berasal dari pengiriman ulang hal yang sudah pernah dilihat, sementara informasi baru di tiap turn hanya sebagian kecil
  • Penggunaan token pada tahap ini belum dioptimalkan — metode penghematan yang diajukan antara lain prompt caching, context compaction, dan mengurangi frekuensi snapshot
  • Karena biaya ini, untuk saat ini pendekatan tersebut lebih cocok untuk debugging terarah dan exploratory testing daripada eksekusi CI berfrekuensi tinggi, meski hal ini dapat membaik dengan model dan alat di masa depan

• Pentingnya infrastruktur (MCP vs CLI)

  • Bukan hanya model, lingkungan eksekusi juga sangat memengaruhi keandalan — MCP 0–12%, CLI 12–20% tingkat kegagalan
  • Sebagian besar kegagalan CLI berasal dari masalah autentikasi dan navigasi (error login, timeout, sesi tidak stabil), yaitu masalah lapisan eksekusi, bukan penalaran agen
  • Playwright MCP menyediakan primitive browser terstruktur dan integrasi yang rapat dengan workflow tool-calling agen, sedangkan CLI menambahkan lapisan ekstra di antara agen dan browser
  • Perbedaan paralelisasi: MCP mudah dijalankan secara paralel, CLI sulit diparalelkan sehingga umumnya dijalankan secara berurutan
  • Keandalan, kecepatan, dan biaya ditentukan bukan hanya oleh model, tetapi juga oleh stabilitas dan desain lingkungan eksekusi

• Batas kemampuan eksekusi (Execution Capability Boundaries)

  • Eksperimen ini berfokus pada workflow UI satu sesi
  • Flow lintas workspace atau workflow yang membuka beberapa jendela browser menghadirkan tantangan lain, di mana pemilihan model eksekusi menjadi sama pentingnya dengan agennya
    • MCP dapat menghadapi masalah biaya karena loop observasi bertambah pada flow panjang
    • CLI berpotensi menghadapi kompleksitas koordinasi dan penggunaan token tinggi saat mengelola banyak sesi browser
  • Keduanya dapat mendukung skenario tersebut, tetapi trade-off-nya berbeda — ini tidak dieksplorasi dalam eksperimen ini, namun menjadi poin penting bagi tim evaluasi

Posisi pengujian agentik dalam test pyramid

• Pengujian agentik tidak menggantikan pendekatan yang ada, melainkan menambahkan kemampuan baru di atasnya

• Pengujian E2E deterministik

  • Paling cocok untuk pemeriksaan regresi yang cepat dan dapat diulang di CI
    • Ditulis manusia atau dihasilkan AI
    • Cepat dan dapat diulang, ramah CI
    • Biaya operasional rendah
    • Memaksakan journey UI tertentu

• Pengujian agentik

  • Berawal dari goal, bukan eksekusi skrip tetap — mengamati UI, menalar status saat ini, dan menentukan cara mencapai hasil yang diinginkan
    • Menjelajahi perilaku UI yang kompleks
    • Debugging workflow yang flaky
    • Mereproduksi bug produksi

• Test pyramid dengan lapisan agentik

  • Dari sudut pandang sistem, pengujian agentik memverifikasi workflow pengguna nyata melalui UI pada level yang sama dengan E2E, dengan perbedaan pada cara workflow dijalankan
  • Strategi pengujian paling efektif di masa depan kemungkinan menggabungkan keduanya — pengujian deterministik menyediakan fondasi stabil untuk CI, sementara pengujian agentik menangani eksplorasi, debugging, dan verifikasi perilaku kompleks di puncak pyramid