Laporan bug adalah alat komunikasi dan juga catatan kerusakan. Laporan yang baik menghemat waktu: pengembang dapat mereproduksi masalah, manajer memahami dampaknya, dan QA dapat melacak perbaikan dan risiko terkait.
Isi umum sebuah laporan
- →Judul yang jelas mengidentifikasi masalah.
- →Lingkungan dan prasyarat yang relevan.
- →Langkah-langkah reproduksi.
- →Hasil aktual dan yang diharapkan.
- →Bukti: tangkapan layar, video, log, jejak jaringan, muatan, atau jejak tumpukan.
Apa yang membuat laporan menjadi kuat
- →Masalahnya mudah untuk dipahami dan direproduksi.
- →Fakta dibedakan dari interpretasi.
- →Dampak pengguna, bisnis, atau sistem dijelaskan.
- →Detail yang tidak relevan tidak mengaburkan keputusan.
Kesalahan umum
- →Judul yang tidak jelas seperti “tombol tidak berfungsi”.
- →Hasil yang diharapkan tidak ada atau terlalu abstrak.
- →Langkah-langkah yang menghilangkan kondisi penting dan tidak dapat mereproduksi cacat.
- →Prioritas dan tingkat keparahan didasarkan pada emosi, bukan risiko.
Panduan praktis
Tulislah untuk seseorang yang tidak terbiasa dengan konteks pengujian Anda. Semakin cepat mereka dapat menentukan apa yang gagal, bagaimana cara mereproduksinya, dan mengapa hal tersebut penting, semakin baik pula laporannya.
Contoh lengkap: laporan cacat yang dapat direproduksi
Berikut adalah contoh latihan fiktif, bukan defect yang diamati pada produk nyata. Anggap persyaratan REG-04 mengizinkan nama panggilan sepanjang 3–12 huruf ASCII, termasuk kedua batasnya. Build contoh keliru menolak nama dengan tepat 3 huruf. Laporan nyata harus tetap terkait dengan persyaratan yang disetujui dan pengamatan aktual.
ID: DEMO-17
Judul: Pendaftaran menolak nama panggilan 3 huruf yang diizinkan REG-04
Lingkungan: build latihan fiktif 1.0; browser dan OS: catat versi sebenarnya
Prasyarat: formulir pendaftaran terbuka; semua kolom lain berisi data valid
Langkah:
1. Masukkan abc pada kolom Nickname.
2. Pindahkan fokus ke kolom berikutnya.
3. Kirim formulir.
Hasil yang diharapkan: tidak ada kesalahan panjang nama panggilan; pendaftaran dapat dilanjutkan.
Hasil aktual dalam skenario fiktif ini: "Minimum 4 characters"; pengiriman diblokir.
Keterulangan: terjadi pada 3 dari 3 percobaan setelah formulir direset.
Dampak: nama panggilan yang diizinkan tidak dapat didaftarkan.
Bukti yang perlu dikumpulkan: tangkapan layar, ID build, waktu, serta request/response tanpa data sensitif.
Persyaratan: REG-04.
Severity / prioritas: sepakati menurut definisi tim dan konteks rilis.Judul menyebutkan tindakan, masukan dan penyimpangan. Ia tidak menduga bahwa backend bertanggung jawab. Jika hanya UI yang teramati, catat fakta tersebut; periksa permintaan sebelum mengklaim penyebab sisi server. Tangkapan layar dan log yang tercantum di atas adalah bukti yang harus dikumpulkan, bukan lampiran yang disediakan oleh panduan ini.
Templat laporan yang dapat disalin
Judul:
Build / lingkungan:
Persyaratan atau sumber perilaku yang diharapkan:
Prasyarat dan data uji:
Langkah:
Hasil yang diharapkan:
Hasil aktual:
Keterulangan:
Dampak bagi pengguna:
Bukti tanpa data sensitif:
Issue / kasus uji terkait:Sebelum mengirim, mintalah rekan satu tim untuk hanya mengikuti langkah-langkah yang tercatat. Hapus kredensial dan data pribadi dari bukti. Laporan yang belum dapat direproduksi masih dapat berguna: nyatakan apa yang diketahui, seberapa sering hal tersebut terjadi, dan informasi apa yang hilang.