Bagi seorang Quality Assurance (QA), tidak ada perasaan yang lebih melegakan daripada menemukan sebuah edge case bug yang krusial. Namun, kebahagiaan itu bisa sirna seketika saat tiket bug yang kita buat di Jira atau Trello di-respons oleh developer dengan kalimat legendaris:

"Di laptop saya aman, kok." atau "Ini maksudnya gimana, ya? Kurang jelas."

Ujung-ujungnya, terjadilah drama "ping-pong" tiket atau debat kusir di Slack yang menghabiskan waktu berjam-jam.

Menemukan bug itu baru setengah dari pekerjaan QA. Setengah sisanya — yang tidak kalah penting — adalah menyajikannya dalam sebuah Bug Report yang tidak bisa dibantah. Menulis bug report adalah sebuah seni komunikasi teknis. Jika ditulis dengan benar, developer tidak akan punya ruang untuk mengelak, melainkan langsung "tobat", paham masalahnya, dan segera memperbaikinya.

Bagaimana caranya? Mari kita bedah anatomi bug report yang ideal beserta panduan praktisnya.

Anatomi Bug Report yang Sempurna

Sebuah bug report yang baik harus menganut prinsip 3W: What, Where, and Under What Conditions. Jangan membuat developer menebak-nebak. Pastikan elemen-elemen berikut ada di dalam tiketmu:

1. Judul yang Jelas dan Spesifik (The Hook)

Hindari judul yang ambigu seperti "Aplikasi Error" atau "Halaman Pembayaran Rusak". Judul harus menggambarkan masalah + lokasi + kondisi.

  • ❌ Buruk: Diskon tidak jalan.
  • ✅ Bagus: [Cart] Kode promo "DISKON20" memicu Error 500 saat checkout dengan metode pembayaran e-wallet.

2. Lingkungan Pengujian (Environment)

Aplikasi bisa berjalan normal di Android 13 tapi hancur di iOS 17. Selalu tulis spesifikasi tempat kamu menemukan bug tersebut.

  • Platform/OS: Android 14, macOS Sonoma
  • Browser/App Version: Chrome v122, App Version v2.4.1
  • Environment: Staging / Production

3. Langkah-Langkah Reproduksi (Steps to Reproduce)

Ini adalah bagian paling krusial. Tuliskan langkah demi langkah dari awal secara berurutan (bullet points). Ingat, tulis seolah-olah kamu sedang menjelaskan ini kepada orang yang baru pertama kali membuka aplikasi tersebut.

4. Hasil Aktual vs Hasil Ekspektasi (Actual vs Expected Result)

Tunjukkan dengan kontras apa yang terjadi saat ini dan apa yang seharusnya terjadi berdasarkan dokumen produk (PRD). Ini adalah poin utama untuk mengunci perdebatan.

5. Bukti Pendukung (Evidence & Logs)

Satu gambar mewakili seribu kata, satu video (screen recording) menyelamatkan puluhan menit waktu debugging. Jika itu bug di backend atau API, lampirkan payload request/response atau error log dari konsol.

1. Implementasi di Jira Card (Issue)

Di Jira Cloud saat ini, kamu bisa langsung copy-paste teks Markdown, atau menggunakan visual editor mereka.

💡 Tips Khusus Jira:

  • Gunakan Fitur Panel (Info/Note/Warning): Jira punya fitur komponen /warning atau /info yang sangat bagus untuk menyorot informasi penting seperti Environment atau Test Data.
  • Gunakan Fitur Table: Untuk bagian Environment, mengubahnya menjadi tabel akan terlihat jauh lebih bersih di Jira.

Contoh Tampilan di Deskripsi Jira:

🐛 Bug Description

User mengalami infinite loading saat mencoba mengunggah foto profil dengan ukuran file tepat 5MB.

🔄 Steps to Reproduce

  • Login ke aplikasi, masuk ke menu Settings > Profile.
  • Klik tombol "Change Avatar".
  • Pilih file gambar yang sudah disediakan di Environment (5.0 MB).
  • Klik "Save Changes".

❌ Actual Result

Aplikasi mengalami infinite loading (spinner berputar terus) dan tidak ada pesan eror di UI.

🎯 Expected Result

Sistem berhasil mengunggah foto karena batas maksimal di PRD adalah 5MB. Jika gagal karena limit server, seharusnya muncul error toast message yang jelas (bukan hang).

📁 Technical Logs & Evidence

  • Console Error / Network Tab:
  • JSON
  • { "status": 413, "error": "Payload Too Large", "message": "The profile image size exceeds maximum limits." }
  • (Seret dan lepas file screenshot/video kamu langsung ke bawah teks ini di Jira)

2. Implementasi di GitHub Card (Issues)

GitHub sangat berorientasi pada developer dan menggunakan GitHub Flavored Markdown (GFM). Kelebihan GitHub adalah kita bisa menggunakan fitur Collapsible Section (<details>) untuk menyembunyikan log yang terlalu panjang agar tiket tidak kepenuhan.

💡 Tips Khusus GitHub:

  • Gunakan Tanda Centang (Tasklist): Pada langkah reproduksi, kamu bisa menggunakan - [ ] jika ingin langkah tersebut bisa dicentang secara interaktif oleh developer saat mereka melakukan debugging.
  • Gunakan <details> untuk Log: Ini trik rahasia QA agar developer senang. Log API yang panjang disembunyikan di dalam dropdown.

Contoh Kode Markdown untuk GitHub Issue:

Markdown

## 🐛 Bug Description
User mengalami *infinite loading* saat mencoba mengunggah foto profil dengan ukuran file tepat 5MB.## 📋 Environment
- **App Version:** Web v1.12.0 (Staging)
- **OS/Browser:** Windows 11 / Edge v122
- **Test Data:** `qa-tester@mail.com`
## 🔄 Steps to Reproduce
- [ ] 1. Login ke aplikasi, pergi ke halaman **Settings > Profile**.
- [ ] 2. Klik tombol **"Change Avatar"**.
- [ ] 3. Pilih file gambar berukuran 5.0 MB.
- [ ] 4. Klik **"Save Changes"**.
## ❌ Actual Result
Loading spinner berputar selamanya dan foto tidak berubah.
## 🎯 Expected Result
Foto profil berhasil diperbarui atau muncul pesan peringatan yang *user-friendly*.
## 📁 Technical Logs & Evidence
* **Screenshot/Video:** (Seret gambar/video ke sini, GitHub akan otomatis membuatkan link-nya)
<details>
<summary><b>Klik di sini untuk melihat Network Log (API Error)</b></summary>
```json
POST /api/v1/user/avatar -> Status 413 (Payload Too Large)
{
  "timestamp": "2026-05-21T14:30:00Z",
  "path": "/api/v1/user/avatar",
  "status": 413,
  "error": "Payload Too Large"
}