Padepokan QA

Anatomi Bug Report yang Disukai Developer

Bug report yang jelas mempercepat perbaikan dan membangun reputasimu sebagai QA. Ini struktur dan contohnya.

Tim Padepokan QA · Senin, 28 September 2026 · 3 menit baca

Jawaban singkat: Bug report yang baik membuat developer bisa mereproduksi masalah tanpa bertanya. Isinya: judul spesifik, lingkungan pengujian, prekondisi, langkah reproduksi, expected result, actual result, severity, dan bukti berupa screenshot atau rekaman layar.

Menemukan bug itu baru setengah pekerjaan. Setengah lainnya adalah melaporkannya dengan jelas sehingga developer bisa mereproduksi dan memperbaikinya tanpa bolak-balik bertanya.

Bug report yang baik juga membangun reputasimu. Developer akan mempercayai laporanmu, dan tim bisa bergerak lebih cepat.

Bagian-bagian bug report

  • Judul: ringkas dan spesifik. Formula sederhana: [Fitur] apa yang salah, dalam kondisi apa.
  • Lingkungan: perangkat, sistem operasi, browser, versi aplikasi.
  • Prekondisi: kondisi awal yang diperlukan.
  • Langkah reproduksi: berurutan, dimulai dari kondisi awal.
  • Expected result: apa yang seharusnya terjadi menurut requirement.
  • Actual result: apa yang sebenarnya terjadi.
  • Severity: seberapa besar dampaknya (Critical, High, Medium, Low).
  • Lampiran: screenshot, rekaman layar, atau log.

Contoh

Judul: [Profil] Tombol "Simpan Alamat" tidak merespons jika kode pos diisi 5 digit diawali angka 0

  • Lingkungan: Chrome 128, Windows 11, versi web 2.4.1
  • Prekondisi: Pengguna sudah login dan berada di halaman Profil → Alamat.
  • Langkah:
  1. Isi semua kolom alamat dengan data valid.
  2. Isi kode pos 07123.
  3. Klik Simpan Alamat.
  • Expected: Alamat tersimpan dan muncul pesan "Alamat berhasil disimpan".
  • Actual: Tombol tidak merespons, tidak ada pesan apa pun. Kode pos 57123 tersimpan normal.
  • Severity: High (pengguna di wilayah tertentu tidak bisa menyimpan alamat pengiriman).
  • Lampiran: rekaman layar 12 detik.

Perhatikan kalimat terakhir di actual result. Membandingkan dengan kondisi yang berhasil membantu developer menemukan akar masalah lebih cepat.

Satu contoh memang belum cukup untuk membiasakan diri. Kalau ingin melihat lebih banyak bug report dari satu fitur yang sama, QA Starter Kit memuat 8 contoh bug report dari studi kasus fitur "Bayar Pajak Daerah", beserta templatenya.

Severity dan priority itu berbeda

  • Severity menjelaskan dampak teknis bug terhadap sistem atau pengguna.
  • Priority menjelaskan seberapa cepat bug perlu diperbaiki, sering diputuskan bersama product owner.

Salah ketik di halaman "Tentang Kami" bisa ber-severity rendah, tetapi priority-nya tinggi jika halaman itu akan dipakai untuk peluncuran besok.

Kebiasaan yang membuat bug report-mu disukai

  1. Satu laporan untuk satu bug.
  2. Reproduksi dulu sebelum melapor. Pastikan bug muncul lebih dari sekali.
  3. Cek duplikat. Mungkin bug yang sama sudah dilaporkan.
  4. Netral dan faktual. Hindari kalimat seperti "fitur ini parah banget".
  5. Sertakan bukti. Satu rekaman layar sering lebih jelas dari satu paragraf penjelasan.

Pertanyaan Umum

Apa bedanya severity dan priority?

Severity menggambarkan seberapa besar dampak bug terhadap sistem atau pengguna. Priority menggambarkan seberapa cepat bug perlu diperbaiki, dan sering diputuskan bersama product owner.

Bagaimana menulis judul bug report yang baik?

Gunakan pola [Fitur] apa yang salah dan dalam kondisi apa. Judul yang spesifik membantu tim memahami masalah tanpa membuka detailnya.

Apa yang dilakukan jika bug tidak selalu muncul?

Catat seberapa sering bug muncul, kondisi saat terjadi, dan semua langkah yang kamu lakukan. Sertakan rekaman layar agar developer punya petunjuk sebanyak mungkin.

Latih sampai jadi kebiasaan

Menulis bug report itu keterampilan, dan keterampilan terbentuk dari latihan. Tulis laporan untuk setiap bug yang kamu temukan, lalu bandingkan dengan contoh yang rapi: apakah judulmu sudah spesifik, langkahmu bisa diulang, dan severity-mu punya alasan?

:::cta

Template dan contoh bug report

QA Starter Kit berisi template bug report dan 8 contoh pengisiannya, ditambah template dan contoh test case, Regression Checklist, Test Plan, dan Test Summary Report. Semua contohnya memakai satu studi kasus, jadi kamu bisa melihat satu fitur diuji dari rencana sampai laporan akhir. Harga Rp99.000.

Lihat isi QA Starter Kit

Butuh bug untuk dilaporkan? Berlatihlah di Arena Latihan WarTicket, lalu laporkan temuanmu langsung dari Panel Latihan. :::