Pelajari cara membuat pengujian penerimaan dari prompt dengan mengubah tiap permintaan fitur menjadi 5–10 skenario jelas, mencakup happy path dan edge case tanpa suite tes yang membengkak.
Prompt bergaya chat terasa jelas karena terbaca seperti percakapan. Tapi seringkali mereka menyisipkan pilihan, aturan, dan pengecualian ke dalam beberapa kalimat ramah. Kekosongan itu baru terlihat saat seseorang benar-benar menggunakan fiturnya.
Sebagian besar prompt diam-diam bergantung pada asumsi: siapa yang boleh melakukan aksi, apa yang dihitung sebagai “sukses” (tersimpan, terkirim, dipublikasikan, terbayar), apa yang terjadi saat data hilang, dan apa yang harus dilihat pengguna ketika sesuatu gagal. Mereka juga menyamarkan standar samar seperti apa yang dimaksud dengan “cukup cepat” atau “cukup aman”.
Ambiguitas biasanya muncul terlambat sebagai bug dan pengerjaan ulang. Pengembang membangun apa yang mereka kira maksud prompt, reviewer menyetujuinya karena terlihat benar, lalu pengguna menemukan kasus aneh: pengiriman duplikat, zona waktu, data parsial, atau ketidaksesuaian izin. Memperbaiki ini kemudian lebih mahal karena sering menyentuh kode, teks UI, dan kadang model data.
Kualitas tidak membutuhkan suite pengujian yang besar. Kualitas berarti Anda bisa mempercayai fitur saat penggunaan normal dan di bawah tekanan yang bisa diprediksi. Sekelompok kecil skenario yang dipilih dengan baik memberi kepercayaan itu tanpa ratusan tes.
Definisi praktis kualitas untuk fitur yang dibangun dari prompt:
Itulah tujuan mengubah prompt menjadi skenario penerimaan: ambil permintaan yang samar dan ubah menjadi 5–10 pemeriksaan yang mengungkap aturan tersembunyi lebih awal. Anda tidak berusaha menguji semuanya. Anda berusaha menangkap kegagalan yang benar-benar terjadi.
Jika Anda membangun dari prompt cepat di alat vibe-coding seperti Koder.ai, output bisa terlihat lengkap sementara masih melewatkan aturan pinggir. Set skenario yang ketat memaksa aturan-aturan itu bernama saat perubahan masih murah.
Skenario pengujian penerimaan adalah deskripsi singkat, bahasa-biasa tentang tindakan pengguna dan hasil yang harus mereka lihat.
Tetap di permukaan: apa yang bisa dilakukan pengguna, dan apa yang produk tampilkan atau ubah. Hindari detail internal seperti tabel database, pemanggilan API, job background, atau framework yang dipakai. Detail itu mungkin penting nanti, tapi membuat skenario rapuh dan lebih sulit disepakati.
Skenario yang baik juga independen. Ia harus mudah dijalankan besok di lingkungan bersih, tanpa bergantung pada skenario lain yang sudah dijalankan terlebih dulu. Jika sebuah skenario bergantung pada state sebelumnya, nyatakan itu dengan jelas di setup (misal, “pengguna sudah memiliki langganan aktif”).
Banyak tim memakai Given–When–Then karena memaksa kejelasan tanpa mengubah skenario jadi spesifikasi penuh.
Sebuah skenario biasanya dianggap “selesai” ketika memiliki satu tujuan, state awal yang jelas, aksi yang konkret, dan hasil yang terlihat. Harus biner: siapa pun di tim bisa mengatakan “lulus” atau “gagal” setelah menjalankannya.
Contoh: “Given pengguna yang sudah masuk dan tidak punya metode pembayaran tersimpan, when mereka memilih Pro dan mengonfirmasi pembayaran, then mereka melihat pesan sukses dan plan ditampilkan sebagai Pro di akun mereka.”
Jika Anda membangun di builder berfokus chat seperti Koder.ai, tetap pakai aturan yang sama: uji perilaku aplikasi yang dihasilkan (apa yang dialami pengguna), bukan bagaimana platform menghasilkan kode.
Format terbaik adalah yang orang-orang benar-benar akan menulis dan membaca. Jika setengah tim memakai narasi panjang dan setengah lagi menulis butir singkat, Anda akan mendapatkan celah, duplikat, dan argumen soal kata alih-alih kualitas.
Given–When–Then cocok ketika fiturnya interaktif dan mempunyai state. Tabel sederhana cocok ketika Anda memiliki aturan input-output dan banyak kasus serupa.
Jika tim terbelah, pilih satu format selama 30 hari dan sesuaikan setelahnya. Jika reviewer terus bertanya “apa yang dimaksud sukses?”, itu biasanya tanda untuk bergerak ke Given–When–Then. Jika skenario jadi bertele-tele, tabel mungkin lebih mudah dipindai.
Apa pun yang Anda pilih, standarkan. Jaga judul yang sama, waktu kata yang sama, dan tingkat detail yang sama. Sepakati juga apa yang tidak boleh dimasukkan: detail pixel-perfect UI, implementasi internal, dan pembicaraan database. Skenario harus menggambarkan apa yang dilihat pengguna dan jaminan sistem.
Letakkan skenario di tempat kerja yang sudah dipakai dan dekat dengan fitur.
Opsi umum termasuk menyimpannya dekat kode produk, di tiket Anda di bawah bagian “Acceptance scenarios”, atau di ruang dokumen bersama dengan satu halaman per fitur. Jika Anda menggunakan Koder.ai, Anda juga bisa menyimpan skenario di Planning Mode agar tetap bersama riwayat build bersamaan snapshot dan titik rollback.
Kunci utamanya adalah membuatnya bisa dicari, menjaga satu sumber kebenaran, dan menuntut skenario sebelum pengembangan dianggap “dimulai.”
Mulai dengan menulis ulang prompt sebagai tujuan pengguna plus garis finish yang jelas. Gunakan satu kalimat untuk tujuan (siapa ingin apa), lalu 2–4 kriteria sukses yang bisa Anda verifikasi tanpa berdebat. Jika Anda tidak bisa menunjuk hasil yang terlihat, itu belum menjadi tes.
Selanjutnya, urai prompt menjadi input, output, dan aturan. Input adalah apa yang disediakan atau dipilih pengguna. Output adalah apa yang sistem tampilkan, simpan, kirim, atau blokir. Aturan adalah pernyataan “hanya jika” dan “harus” yang tersembunyi di antara baris.
Lalu periksa apa yang diperlukan fitur sebelum bisa bekerja. Di sinilah celah skenario bersembunyi: data yang wajib ada, peran pengguna, izin, integrasi, dan state sistem. Misalnya, jika Anda membangun aplikasi di Koder.ai, sebutkan apakah pengguna harus login, punya proyek, atau memenuhi syarat plan atau akses sebelum aksi bisa dilakukan.
Sekarang tulis kumpulan skenario terkecil yang membuktikan fitur bekerja: biasanya 1–2 happy path, lalu 4–8 edge case. Buat setiap skenario fokus pada satu alasan kegagalan.
Edge case yang baik dipilih (hanya apa yang cocok dengan prompt): input hilang atau tidak valid, mismatch izin, konflik state seperti “sudah dikirim,” masalah dependensi eksternal seperti timeout, dan perilaku pemulihan (pesan error jelas, retry yang aman, tidak ada penyimpanan parsial).
Selesaikan dengan pemeriksaan cepat “apa yang bisa salah?”. Cari kegagalan diam-diam, pesan membingungkan, dan tempat di mana sistem bisa membuat data salah.
Skenario happy path adalah rute paling pendek dan normal di mana semuanya berjalan lancar. Jika Anda sengaja membuatnya membosankan, ia menjadi baseline andal yang membuat edge case lebih mudah ditemukan nanti.
Beri nama pengguna default dan data default. Gunakan peran nyata, bukan sekedar “User”: “Pelanggan yang sudah masuk dengan email terverifikasi” atau “Admin dengan izin mengedit tagihan.” Kemudian tentukan data sampel paling kecil yang masuk akal: satu proyek, satu item dalam daftar, satu metode pembayaran tersimpan. Ini menjaga skenario konkret dan mengurangi asumsi tersembunyi.
Tulis jalur terpendek ke sukses terlebih dahulu. Hapus langkah opsional dan alur alternatif. Jika fiturnya “Buat tugas,” happy path tidak perlu mencakup penyaringan, pengurutan, atau pengeditan setelah pembuatan.
Cara sederhana untuk menjaga ketat adalah mengonfirmasi empat hal:
Lalu tambahkan satu varian yang mengubah hanya satu variabel. Pilih variabel yang paling mungkin rusak nanti, seperti “judul panjang” atau “pengguna tidak punya item sebelumnya,” dan biarkan semuanya lain identik.
Contoh: jika prompt mengatakan, “Tambahkan toast ‘Snapshot created’ setelah menyimpan snapshot,” happy path-nya adalah: pengguna klik Create Snapshot, melihat state loading, mendapat “Snapshot created,” dan snapshot muncul di daftar dengan timestamp yang benar. Varian satu-variabel bisa sama persis, tetapi dengan nama kosong dan aturan penamaan default yang jelas.
Edge case adalah tempat sebagian besar bug bersembunyi, dan Anda tidak perlu suite besar untuk menemukannya. Untuk setiap prompt fitur, pilih sejumlah kecil yang mencerminkan perilaku nyata dan mode kegagalan nyata.
Kategori umum untuk dipilih:
Tidak setiap fitur butuh semua kategori. Kotak pencarian lebih peduli input. Alur pembayaran lebih peduli integrasi dan data.
Pilih edge case yang sesuai risiko: biaya kegagalan tinggi (uang, keamanan, privasi), frekuensi tinggi, alur mudah rusak, bug masa lalu, atau masalah yang sulit dideteksi belakangan.
Contoh: untuk “pengguna mengubah plan langganan,” skenario yang efektif biasanya adalah kadaluwarsa sesi saat checkout, klik ganda pada “Confirm,” dan timeout penyedia pembayaran yang meninggalkan plan tidak berubah sambil menampilkan pesan jelas.
Contoh prompt fitur (bahasa biasa):
"When I break something, I want to roll my app back to a previous snapshot so the last working version is live again."
Di bawah ini set skenario ringkas. Tiap skenario pendek, tapi menegaskan hasil.
S1 [Must-have] Roll back ke snapshot terbaru
Given saya sudah masuk dan saya pemilik app
When saya memilih “Rollback” dan mengonfirmasi
Then aplikasi deploy snapshot sebelumnya dan status aplikasi menunjukkan versi baru sebagai aktif
S2 [Must-have] Roll back ke snapshot tertentu
Given saya melihat daftar snapshot untuk aplikasi saya
When saya memilih snapshot “A” dan mengonfirmasi rollback
Then snapshot “A” menjadi versi aktif dan saya dapat melihat kapan dibuat
S3 [Must-have] Tidak diizinkan (auth)
Given saya sudah masuk tetapi saya tidak punya akses ke aplikasi ini
When saya mencoba melakukan rollback
Then saya melihat error akses dan tidak ada rollback yang dimulai
S4 [Must-have] Snapshot tidak ditemukan (validasi)
Given sebuah ID snapshot tidak ada (atau sudah dihapus)
When saya mencoba rollback ke ID itu
Then saya mendapatkan pesan “snapshot tidak ditemukan” yang jelas
S5 [Must-have] Submit ganda (duplikat)
Given saya mengklik “Confirm rollback” dua kali dengan cepat
When request kedua dikirim
Then hanya satu rollback yang berjalan dan saya melihat satu hasil saja
S6 [Must-have] Kegagalan deployment (gagal)
Given rollback sudah dimulai
When deployment gagal
Then versi aktif saat ini tetap live dan error ditampilkan
S7 [Nice-to-have] Timeout atau koneksi hilang
Given koneksi saya terputus di tengah rollback
When saya memuat ulang halaman
Then saya dapat melihat apakah rollback masih berjalan atau sudah selesai
S8 [Nice-to-have] Sudah pada snapshot itu
Given snapshot “A” sudah aktif
When saya mencoba rollback ke snapshot “A”
Then saya diberi tahu tidak ada yang berubah dan tidak ada deployment baru yang dimulai
Setiap skenario menjawab tiga pertanyaan: siapa yang melakukannya, apa yang mereka lakukan, dan apa yang harus benar setelahnya.
Tujuannya bukan “uji semuanya.” Tujuannya menutup risiko yang merugikan pengguna, tanpa menciptakan timbunan skenario yang tidak ada yang menjalankan.
Trik praktis adalah memberi label skenario berdasarkan bagaimana Anda mengharapkan menggunakannya:
Batasi diri pada satu skenario per risiko berbeda. Jika dua skenario gagal karena alasan yang sama, Anda mungkin hanya perlu satu. “Format email tidak valid” dan “email hilang” adalah risiko berbeda. Tapi “email hilang di Langkah 1” dan “email hilang di Langkah 2” mungkin sama risikonya jika aturannya identik.
Juga hindari menduplikasi langkah UI di banyak skenario. Singkatkan bagian yang berulang dan fokus pada apa yang berubah. Ini lebih penting lagi saat membangun di alat berbasis chat seperti Koder.ai, karena UI bisa berubah sementara aturan bisnis tetap sama.
Terakhir, putuskan apa yang diperiksa sekarang vs nanti. Beberapa cek lebih baik manual dulu, lalu diotomasi setelah fitur stabil:
Skenario harus melindungi Anda dari kejutan, bukan menggambarkan bagaimana tim berencana membangun fitur.
Kegagalan paling umum adalah mengubah tujuan pengguna menjadi checklist teknis. Jika skenario mengatakan “API mengembalikan 200” atau “tabel X punya kolom Y,” itu mengunci desain dan tetap tidak membuktikan pengguna mendapat apa yang mereka butuhkan.
Masalah lain adalah menggabungkan banyak tujuan jadi satu skenario panjang. Terlihat seperti perjalanan penuh, tapi saat gagal, tidak ada yang tahu kenapa. Satu skenario harus menjawab satu pertanyaan.
Berhati-hatilah terhadap edge case yang terdengar pintar tapi tidak nyata. “Pengguna punya 10 juta proyek” atau “jaringan putus setiap 2 detik” jarang cocok produksi dan sulit direproduksi. Pilih edge case yang bisa disiapkan dalam hitungan menit.
Juga hindari hasil yang samar seperti “bekerja”, “tanpa error”, atau “selesai dengan sukses.” Kata-kata itu menyembunyikan hasil tepat yang harus Anda verifikasi.
Jika Anda membangun fitur seperti fitur “ekspor source code” Koder.ai, skenario lemah adalah: “Saat user klik ekspor, sistem mengzip repo dan mengembalikan 200.” Itu menguji implementasi, bukan janji.
Skenario yang lebih baik: “Given sebuah proyek dengan dua snapshot, when user mengekspor, then unduhan berisi kode snapshot saat ini dan log ekspor mencatat siapa yang mengekspor dan kapan.”
Jangan lupa jalur “tidak”: “Given pengguna tanpa izin ekspor, when mereka mencoba ekspor, then opsi disembunyikan atau diblokir, dan tidak ada catatan ekspor dibuat.” Satu baris bisa melindungi keamanan dan integritas data.
Sebelum Anda menganggap set skenario “selesai,” bacalah seperti pengguna yang cerewet dan seperti database. Jika Anda tidak bisa tahu apa yang harus benar sebelum tes dimulai, atau apa yang dimaksud dengan “sukses”, itu belum siap.
Set yang baik kecil tapi spesifik. Anda harus bisa menyerahkannya ke orang yang tidak menulis fitur dan mendapatkan hasil yang sama.
Gunakan pemeriksaan singkat ini untuk menyetujui (atau mengembalikan) skenario:
Jika Anda menghasilkan skenario di builder berbasis chat seperti Koder.ai, tuntut standar yang sama: jangan terima “bekerja seperti yang diharapkan” yang samar. Mintalah output yang dapat diamati dan perubahan yang tersimpan, lalu setujui hanya apa yang bisa Anda verifikasi.
Jadikan penulisan skenario sebagai langkah nyata dalam proses Anda, bukan tugas pembersihan di akhir.
Tulis skenario sebelum implementasi dimulai, saat fitur masih murah diubah. Ini memaksa tim menjawab pertanyaan canggung lebih awal: apa arti “sukses”, apa yang terjadi pada input buruk, dan apa yang belum didukung.
Gunakan skenario sebagai definisi bersama tentang “selesai.” Product memegang intent, QA memegang pemikiran risiko, dan engineering memegang kelayakan. Ketika ketiganya bisa membaca set skenario yang sama dan sepakat, Anda menghindari mengirim sesuatu yang “selesai” tapi tidak dapat diterima.
Alur kerja yang tahan di sebagian besar tim:
Jika Anda membangun di Koder.ai (koder.ai), menulis skenario dulu lalu memakai Planning Mode dapat membantu memetakan setiap skenario ke layar, aturan data, dan hasil yang terlihat pengguna sebelum Anda menghasilkan atau mengedit kode.
Untuk perubahan berisiko, ambil snapshot sebelum mulai iterasi. Jika edge case baru merusak alur yang semula berfungsi, rollback dapat menyelamatkan Anda dari menghabiskan sehari merapikan efek samping.
Simpan skenario dekat permintaan fitur (atau di dalam tiket yang sama) dan perlakukan mereka seperti requirement yang diberi versi. Ketika prompt berkembang, set skenario harus berkembang juga, atau definisi “selesai” Anda akan diam-diam bergeser.
Mulailah dengan satu kalimat yang menyatakan tujuan pengguna dan garis selesai.
Lalu pecah prompt menjadi:
Dari situ, tulis 1–2 happy path ditambah 4–8 edge case yang sesuai dengan risiko nyata (izin, duplikat, timeout, data hilang).
Karena prompt menyembunyikan asumsi. Sebuah prompt mungkin mengatakan “simpan”, tapi tidak mendefinisikan apakah itu draft vs published, apa yang terjadi saat gagal, atau siapa yang boleh melakukannya.
Skenario memaksa Anda untuk menamai aturan lebih awal, sebelum Anda mengirim bug seperti pengiriman duplikat, ketidaksesuaian izin, atau hasil yang tidak konsisten.
Gunakan Given–When–Then ketika fiturnya memiliki state dan interaksi pengguna.
Gunakan tabel input/output sederhana ketika Anda punya banyak pemeriksaan aturan yang serupa.
Pilih satu format selama sebulan dan standarkan (tata bahasa yang sama, tingkat detail yang sama). Format terbaik adalah yang benar-benar tim Anda akan gunakan.
Skenario yang baik adalah:
Skenario dianggap selesai ketika siapa pun bisa menjalankannya dan sepakat pada hasil tanpa perdebatan.
Fokus pada perilaku yang dapat diamati:
Hindari detail implementasi seperti tabel database, kode respons API, job background, atau framework. Detail-detail itu sering berubah dan tidak membuktikan pengguna mendapatkan hasil yang mereka butuhkan.
Tulis jalur paling membosankan dan normal di mana semuanya berjalan lancar:
Lalu verifikasi empat hal: layar/state benar, pesan sukses jelas, data tersimpan, dan pengguna bisa melanjutkan ke tindakan selanjutnya.
Pilih edge case berdasarkan risiko dan frekuensi:
Targetkan , bukan setiap variasi kecil.
Buat aman dan jelas:
Skenario kegagalan harus membuktikan sistem tidak merusak data atau menyesatkan pengguna.
Perlakukan output Koder.ai seperti aplikasi lain: uji apa yang dialami pengguna, bukan bagaimana kode dihasilkan.
Pendekatan praktis:
Simpan di tempat kerja yang sudah dipakai dan punya satu sumber kebenaran:
Jika menggunakan Koder.ai, simpan skenario di Planning Mode agar tetap terkait dengan riwayat build. Yang paling penting: minta skenario sebelum pengembangan dianggap dimulai.
