Hari ketujuh belajar SQA, dan ini hari pertama aku beneran hunting bug di aplikasi nyata.

Bukan simulasi, bukan contoh dari tutorial, tapi buka browser, masuk ke aplikasi, dan nyari sendiri apa yang rusak. Rasanya beda banget. Lebih deg-degan, lebih seru, dan ternyata lebih tricky dari yang aku bayangkan.

Bug Report Itu Bukan Sekadar "Ada Bug di Sini"

Sebelum praktek, aku baca dulu struktur bug report yang bener. Dan aku sadar, selama ini waktu nemuin bug di project sendiri, aku cuma nulis sesuatu seperti"tombol X nggak jalan" di sticky note atau Notion seadanya.

Ternyata bug report yang proper itu punya struktur yang jauh lebih detail:

Kelihatannya banyak, tapi setelah dipraktekin, setiap kolom itu ada alasannya.

Hunting Bug di Saucedemo.com

Aku buka saucedemo.com, aplikasi e-commerce demo yang memang dirancang untuk latihan QA. Login menggunakan akun error_user, lalu mulai eksplor.

Sekitar 2 menit eksplorasi, aku langsung nemu sesuatu yang menarik: tombol "Remove" di halaman Products tidak berfungsi sama sekali.

Klik sekali, nggak ada respon. Klik lagi, tetap nggak ada respon. Produk tetap ada di halaman, icon cart tetap nunjukin angka yang sama.

Bug Report Pertamaku

Ini hasil bug report yang aku buat:

Severity High, Priority Medium: Kok Bisa Beda?

Ini yang paling menarik dari proses hari ini dan yang paling sering bikin bingung orang baru di QA.

Severity = seberapa parah dampaknya ke user dan sistem. Priority = seberapa cepat harus diperbaiki oleh developer.

Kenapa bug ini aku kasih Severity High tapi Priority Medium?

Severity High karena dampaknya ke user cukup serius. Bayangin user sudah klik "Remove", merasa produknya sudah terhapus, tapi ternyata nggak. Waktu checkout, produk yang nggak diinginkan itu masih ada. User baru sadar setelah lihat total harga yang aneh dan harus balik lagi ke keranjang untuk hapus. Itu pengalaman yang merepotkan.

Priority Medium karena masih ada workaround. User tetap bisa hapus produk lewat halaman keranjang secara langsung. Bug-nya mengganggu, tapi tidak totally blocking. Ada jalan lain yang bisa dilakukan sementara bug ini belum diperbaiki.

Jadi Severity dan Priority bisa berbeda dan alasannya harus bisa dijelaskan, bukan hanya feeling saja.

Ada Dua Format Bug Report yang Perlu Kamu Tahu

Waktu belajar ini, aku juga nemu bahwa di dunia kerja nyata, bug report tidak selalu dalam format tabel panjang.

Format Formal dipakai di tools seperti Jira atau Google Sheets. Lengkap dengan semua komponen di atas. Ini standar yang dipelajari dan yang paling sering ditanyain saat interview.

Summary Testing format ringkas yang dishare ke tim via Slack atau Discord setelah sesi testing selesai. Lebih ke komunikasi cepat, tidak perlu step by step, yang penting defect-nya disampaikan dengan jelas ke tim.

Dua-duanya punya tempat masing-masing. Tapi untuk level entry, yang wajib dikuasai dulu adalah format formal.

🔍 Dev Lens

Sebagai developer, aku terbiasa nemuin bug tapi nggak terbiasa mendokumentasikannya dengan benar.

Biasanya kalau nemu bug di project sendiri, aku langsung fix tanpa catat apapun. Akibatnya? Kalau bug yang sama muncul lagi, aku harus debug dari nol karena nggak ada rekaman apa yang pernah terjadi.

Bug report yang proper adalah memory eksternal, bukan hanya untuk developer yang akan fix, tapi juga buat QA yang akan retest, dan buat tim yang perlu tahu status-nya.

💬 Jujur Corner

Yang paling tricky hari ini bukan nemuin bugnya, tapi nentuin Severity vs Priority.

Awalnya aku set keduanya Medium. Tapi setelah dipikir lagi dari sudut pandang user, gimana kalau mereka nggak sadar produknya belum kehapus dan langsung checkout?so, aku ubah Severity ke High.

Pelajaran hari ini: berpikir dari sudut pandang user itu skill yang perlu dilatih, terutama untuk developer yang biasanya berpikir dari sudut pandang sistem.

Takeaway

• Bug report bukan sekadar "ada yang rusak". Ada struktur yang bikin bug bisa ditracking, diprioritaskan, dan diperbaiki dengan efisien
• Severity dan Priority bisa beda. Severity soal dampak, Priority soal urgensi perbaikan
• Format formal vs summary testing, dua-duanya ada tempatnya, tapi formal yang wajib dikuasai dulu
• Berpikir dari sudut pandang user itu kunci dalam menentukan Severity yang tepat

Besok aku masuk ke fase yang lebih seru ywaitu testing aplikasi nyata lebih dalam, regression testing, sampai bikin test plan pertamaku. Follow dulu biar nggak ketinggalan! 👋

— Isna, developer yang lagi belajar ngobrak-abrik software