05 Jan 2026·5 menit
Debug laporan bug yang bukan Anda tulis: alur kerja praktis
Debug laporan bug yang bukan Anda tulis dengan alur kerja praktis untuk reproduksi masalah, mengisolasi UI/API/DB, dan meminta perbaikan AI minimal yang bisa diuji.
Debug laporan bug yang bukan Anda tulis dengan alur kerja praktis untuk reproduksi masalah, mengisolasi UI/API/DB, dan meminta perbaikan AI minimal yang bisa diuji.
Mendiagnosis bug yang dilaporkan oleh orang lain lebih sulit karena Anda tidak punya peta mental pembuat aslinya. Anda tidak tahu apa yang rentan, apa yang "normal", atau jalan pintas apa yang diambil. Gejala kecil (tombol, salah ketik, layar lambat) bisa berasal dari masalah yang lebih dalam di API, database, atau job background.
Laporan bug yang berguna memberi Anda empat hal:
Kebanyakan laporan hanya memberi yang terakhir: "Simpan tidak bekerja," "rusak," "error acak." Yang hilang adalah konteks yang membuatnya dapat diulang: peran pengguna, record spesifik, environment (prod vs staging), dan apakah ini mulai setelah sebuah perubahan.
Tujuannya adalah mengubah gejala samar menjadi reproduksi yang dapat diandalkan. Setelah Anda bisa membuatnya terjadi sesuai permintaan, itu bukan misteri lagi. Itu adalah rangkaian pemeriksaan.
Yang bisa Anda kendalikan segera:
"Selesai" bukanlah "Saya kira saya sudah memperbaikinya." Selesai adalah: langkah reproduksi Anda lulus setelah perubahan kecil, dan Anda dengan cepat menguji ulang perilaku sekitar yang mungkin terpengaruh.
Cara tercepat membuang waktu adalah mengubah banyak hal sekaligus. Bekukan titik awal Anda sehingga setiap hasil uji berarti sesuatu.
Pilih satu environment dan tetap di situ sampai Anda bisa mereproduksi masalah. Jika laporan datang dari produksi, konfirmasi di sana dulu. Jika itu berisiko, gunakan staging. Lokal juga bisa jika Anda bisa menyesuaikan data dan pengaturan dengan dekat.
Lalu tetapkan kode yang sebenarnya berjalan: versi, tanggal build, dan feature flag atau konfigurasi yang memengaruhi alur. Perbedaan kecil (integrasi dimatikan, base URL API berbeda, job background hilang) bisa mengubah bug nyata menjadi hantu.
Buat setup uji yang bersih dan dapat diulang. Gunakan akun baru dan data yang diketahui. Jika bisa, reset state sebelum tiap percobaan (logout, bersihkan cache, mulai dari record yang sama).
Tulis asumsi saat Anda berjalan. Ini bukan kerja sia-sia; ini menghentikan Anda berdebat dengan diri sendiri nanti.
Contoh catatan baseline:
Jika reproduksi gagal, catatan ini memberi tahu apa yang harus Anda variasi selanjutnya, satu kenop (knob) pada satu waktu.
Kemenangan tercepat adalah mengubah keluhan samar menjadi sesuatu yang bisa Anda jalankan seperti skrip.
Mulai dengan menulis ulang laporan sebagai user story singkat: siapa melakukan apa, di mana, dan apa yang mereka harapkan. Lalu tambahkan hasil yang diamati.
Contoh penulisan ulang:
"Sebagai admin billing, ketika saya mengubah status invoice menjadi Paid dan klik Simpan di halaman invoice, status seharusnya tetap. Sebaliknya, halaman tetap sama dan status tidak berubah setelah refresh."
Selanjutnya, tangkap kondisi yang membuat laporan menjadi benar. Bug sering bergantung pada satu detail yang hilang: peran, keadaan record, locale, atau environment.
Input kunci yang harus dicatat sebelum Anda klik di sekitar:
Kumpulkan bukti saat Anda masih melihat perilaku asli. Screenshot membantu, tapi rekaman singkat lebih baik karena menangkap timing dan klik tepat. Selalu catat timestamp (termasuk zona waktu) agar Anda bisa mencocokkannya dengan log nanti.
Tiga pertanyaan klarifikasi yang menghilangkan tebakan terbanyak:
Jangan mulai dengan menebak penyebab. Buat masalah itu terjadi dengan sengaja, dengan cara yang sama, lebih dari sekali.
Pertama, jalankan langkah pelapor persis seperti tertulis. Jangan "memperbaiki" langkahnya. Catat tempat pertama pengalaman Anda berbeda, bahkan jika tampak sepele (label tombol berbeda, field hilang, teks error sedikit berbeda). Ketidaksesuaian pertama itu sering petunjuk.
Alur sederhana yang bekerja di kebanyakan aplikasi:
Setelah bisa diulang, variasikan satu hal pada satu waktu. Tes satu-variabel yang biasanya memberi hasil:
Akhiri dengan skrip repro singkat yang orang lain bisa jalankan dalam 2 menit: keadaan awal, langkah, input, dan pengamatan gagal pertama.
Sebelum Anda membaca seluruh codebase, putuskan lapisan mana yang gagal.
Tanya: apakah gejala hanya di UI, atau juga di data dan respons API?
Contoh: "Nama profil saya tidak terupdate." Jika API mengembalikan nama baru tetapi UI masih menampilkan yang lama, curigai state/caching UI. Jika API tidak pernah menyimpannya, kemungkinan besar di API atau DB.
Pertanyaan triase cepat yang bisa Anda jawab dalam beberapa menit:
Pemeriksaan UI berkaitan dengan visibilitas: error di console, tab Network, dan state usang (UI tidak re-fetch setelah save, atau membaca dari cache lama).
Pemeriksaan API berkaitan dengan kontrak: payload (field, tipe, ID), status code, dan body error. 200 dengan body yang mengejutkan bisa sama pentingnya dengan 400.
Pemeriksaan DB berkaitan dengan kenyataan: baris hilang, tulis parsial, kegagalan constraint, update yang mempengaruhi nol baris karena WHERE clause tidak cocok.
Untuk tetap terarah, buatlah peta kecil: aksi UI mana memicu endpoint mana, dan tabel mana yang dibaca atau ditulis.
Kejelasan sering muncul dengan mengikuti satu request nyata dari klik hingga database dan kembali.
Tangkap tiga jangkar dari laporan atau repro Anda:
Jika Anda tidak punya correlation ID, tambahkan satu di gateway/backend dan sertakan di header respons dan log.
Untuk menghindari kebanjiran noise, ambil hanya yang diperlukan untuk menjawab "Di mana gagal dan kenapa?":
Sinyal yang perlu diperhatikan:
Jika "bekerja kemarin" tapi tidak hari ini, curigai drift environment: flag yang berubah, secret yang diputar, migrasi yang belum dijalankan, atau job yang berhenti berjalan.
Bug termudah diperbaiki adalah eksperimen kecil dan dapat diulang.
Perkecil semuanya: klik lebih sedikit, field lebih sedikit, dataset terkecil yang masih gagal. Jika hanya terjadi pada "pelanggan dengan banyak record," coba buat kasus minimal yang tetap memicunya. Jika tidak bisa, itu petunjuk bug terkait volume data.
Pisahkan "state buruk" dari "kode buruk" dengan mereset state secara sengaja: akun bersih, tenant atau dataset baru, build yang diketahui.
Salah satu cara praktis menjaga repro tetap jelas adalah tabel input ringkas:
| Given (setup) | When (action) | Expect | Got |
|---|---|---|---|
| User role: Editor; satu record dengan Status=Draft | Klik Save | Toast "Saved" + timestamp terupdate | Tombol menampilkan spinner lalu berhenti; tidak ada perubahan |
Buat repro portable agar orang lain bisa menjalankannya cepat:
Jalur tercepat biasanya membosankan: ubah satu hal, amati, catat.
Kesalahan umum:
Contoh realistis: tiket mengatakan "Export CSV kosong." Anda menguji dengan akun admin dan melihat data. Pengguna punya role terbatas, dan API mengembalikan daftar kosong karena filter permission. Jika Anda hanya menambal UI untuk menampilkan "No rows," Anda melewatkan pertanyaan sebenarnya: apakah role itu seharusnya diizinkan mengekspor, atau produk harus menjelaskan mengapa datanya terfilter?
Setelah perbaikan apa pun, jalankan ulang langkah repro yang sama, lalu uji satu skenario terdekat yang seharusnya tetap berfungsi.
Anda akan mendapat jawaban lebih baik dari rekan (atau alat) jika membawa paket yang rapat: langkah yang dapat diulang, satu lapisan yang kemungkinan gagal, dan bukti.
Sebelum siapa pun mengubah kode, konfirmasi:
Lalu lakukan pemeriksaan regresi singkat: coba role berbeda, browser/window private kedua, satu fitur terdekat yang menggunakan endpoint/tabel sama, dan input edge-case (kosong, teks panjang, karakter khusus).
Pesan support: "Tombol Simpan tidak melakukan apa-apa di form Edit Customer." Tindak lanjut mengungkap ini hanya terjadi untuk customer yang dibuat sebelum bulan lalu, dan hanya saat Anda mengubah billing email.
Mulai dari UI dan anggap kegagalan paling sederhana dulu. Buka record, lakukan edit, dan cari tanda bahwa "tidak ada" sebenarnya sesuatu: tombol nonaktif, toast tersembunyi, pesan validasi yang tidak dirender. Buka console browser dan tab Network.
Di sini, klik Simpan memicu request, tapi UI tidak pernah menampilkan hasil karena frontend hanya menganggap 200 sebagai sukses dan mengabaikan error 400. Tab Network menunjukkan respons 400 dengan body JSON seperti: {\"error\":\"billingEmail must be unique\"}.
Sekarang verifikasi API memang gagal: ambil payload persis dari request dan replay. Jika gagal di luar UI juga, hentikan pengejaran bug state frontend.
Lalu periksa database: mengapa pengecekan unik hanya gagal untuk record lama? Anda menemukan pelanggan legacy berbagi billing_email placeholder bertahun-tahun lalu. Pengecekan unik baru kini memblokir penyimpanan siapa pun yang masih memakai placeholder itu.
Repro minimal yang bisa Anda serahkan:
billing_email = [email protected].billingEmail must be unique.Acceptance test: ketika API mengembalikan error validasi, UI menampilkan pesan tersebut, mempertahankan edit pengguna, dan error menyebut field yang gagal secara spesifik.
Setelah bug dapat direproduksi dan Anda mengidentifikasi lapisan yang kemungkinan, minta bantuan dengan cara yang menghasilkan patch kecil dan aman.
Kemas "file kasus" sederhana: langkah repro minimal (dengan input, environment, role), expected vs actual, mengapa Anda berpikir ini UI/API/DB, dan cuplikan log kecil yang menunjukkan kegagalan.
Lalu buat permintaan itu sempit:
Jika Anda menggunakan platform vibe-coding seperti Koder.ai (koder.ai), pendekatan file-kasus ini yang menjaga saran tetap fokus. Snapshot dan rollback-nya juga membantu menguji perubahan kecil dengan aman dan kembali ke baseline yang dikenal.
Serahkan ke developer berpengalaman ketika perbaikan menyentuh keamanan, pembayaran, migrasi data, atau apa pun yang bisa merusak data produksi. Juga serahkan jika perubahan terus berkembang melampaui patch kecil atau Anda tidak bisa menjelaskan risikonya dalam kata-kata sederhana.
Mulai dengan menuliskannya ulang menjadi skrip yang bisa direproduksi: siapa (peran), di mana (halaman/alur), input tepat apa (ID, filter, payload), apa yang Anda harapkan, dan apa yang Anda lihat. Jika ada bagian yang hilang, minta satu akun contoh dan satu ID record contoh agar Anda bisa menjalankan skenario yang sama ujung ke ujung.
Pilih satu lingkungan dan tetap di situ sampai Anda bisa mereproduksi. Catat build/versi, feature flag, konfigurasi, akun/role pengujian, dan data tepat yang Anda gunakan. Ini mencegah Anda “memperbaiki” bug yang sebenarnya muncul karena pengaturan Anda berbeda dari pelapor.
Buat terjadi dua kali dengan langkah dan input yang sama, lalu hapus apa pun yang tidak diperlukan. Targetkan 3–6 langkah dari kondisi start bersih dengan satu record ulang-pakai atau body request. Jika Anda tidak bisa mengecilkannya, itu sering menandakan masalah terkait volume data, timing, atau job background.
Jangan ubah apa pun dulu. Jalankan langkah pelapor persis seperti tertulis, dan catat titik pertama di mana pengalaman Anda berbeda (label tombol berbeda, field hilang, teks error berbeda). Perbedaan pertama itu sering menjadi petunjuk kondisi nyata yang memicu bug.
Periksa apakah datanya benar-benar berubah. Jika API mengembalikan nilai baru tetapi UI masih menampilkan yang lama, kemungkinan masalah pada state UI, caching, atau re-fetch. Jika respons API salah atau simpanan tidak pernah terjadi, fokuslah pada API atau DB. Jika baris DB tidak terupdate (atau terupdate nol baris), masalah ada di lapisan persistensi atau kondisi query.
Pastikan ada request jaringan saat Anda klik tombol, lalu periksa payload request dan body respons, bukan hanya kode status. Catat timestamp (dengan zona waktu) dan identifier pengguna sehingga Anda bisa mencocokkannya ke log backend. Sebuah 200 “sukses” dengan body yang tak terduga bisa sama pentingnya dengan 400/500.
Ubah satu pengaturan pada satu waktu: role, record (baru vs legacy), browser/perangkat, sesi bersih (incognito/cache dibersihkan), dan jaringan. Pengujian satu-variabel akan memberitahu Anda kondisi mana yang penting, dan menghindarkan Anda dari mengejar kebetulan yang muncul karena mengubah banyak hal sekaligus.
Mengubah banyak variabel sekaligus, menguji di lingkungan berbeda dari pelapor, dan mengabaikan role/permissions adalah pemboros waktu terbesar. Perangkap umum lain: memperbaiki gejala permukaan di UI sementara error validasi API/DB masih terjadi di bawahnya. Selalu jalankan ulang repro yang sama setelah perubahan dan kemudian uji satu skenario terdekat.
“Selesai” berarti: repro minimal asli sekarang lulus, dan Anda telah menguji ulang satu alur terdekat yang bisa terpengaruh. Buat ceknya konkret, misalnya sinyal sukses yang terlihat, respons HTTP yang benar, atau perubahan baris DB yang diharapkan. Hindari “sepertinya sudah beres” tanpa menjalankan ulang input yang sama pada baseline yang sama.
Berikan file kasus yang ketat: langkah minimal dengan input tepat, environment/build/flag, akun pengujian dan role, expected vs actual, dan satu bukti (request/response, teks error, atau potongan log dengan timestamp). Lalu minta patch terkecil yang membuat repro lulus dan sertakan rencana uji kecil. Jika Anda menggunakan Koder.ai, memasangkan file kasus ini dengan snapshot/rollback membantu menguji perubahan kecil dengan aman dan kembali jika perlu.