1.6.1

1.6 Penyelesaian Bug

Dalam proses pengembangan perangkat lunak, menemukan bug hanyalah langkah awal dari proses yang lebih panjang, yaitu penyelesaian bug (bug resolution). Setelah tim QA menemukan bug dan mencatatnya ke dalam sistem pelacakan (issue tracker), langkah berikutnya adalah memastikan bug tersebut ditangani oleh tim yang tepat dan diselesaikan dengan benar. Namun, menyelesaikan bug tidak sesederhana "langsung diperbaiki". Ada beberapa  tahapan penting yang harus dilalui agar solusi yang diberikan benar-benar menyelesaikan akar masalah dan tidak menimbulkan masalah baru seperti regresi (bug baru yang muncul akibat perbaikan sebelumnya).

Proses penyelesaian bug melibatkan banyak pihak dalam tim pengembang, yaitu QA yang bertugas mendeteksi dan mendeskripsikan masalah dengan jelas, developer yang menganalisis akar penyebab dan memperbaiki kode, product owner yang menentukan tingkat prioritas perbaikan berdasarkan dampaknya terhadap pengguna atau bisnis, serta kadang-kadang customer support yang menyampaikan keluhan dan kebutuhan pengguna akhir ke tim teknis.

Adapun tahapan umum dalam proses bug resolution mencakup beberapa langkah penting, yaitu:

1. Bug Triage (peninjauan awal) untuk memastikan bug tersebut valid dan layak ditindaklanjuti,
2. Prioritization, tidak semua bug harus langsung diperbaiki, maka dari itu bug diklasifikasikan berdasarkan dampaknya terhadap sistem dan urgensi perbaikannya,
3. Assignment, yaitu menentukan siapa yang akan bertanggung jawab memperbaiki bug,
4. Fixing, proses teknis memperbaiki bug di level kode,
5. Verification, memastikan perbaikan sudah berhasil dan tidak menimbulkan masalah baru,
6. Closure/Done, saat bug ditandai sebagai selesai setelah diverifikasi QA.

Jika proses ini tidak dijalankan dengan baik, bug bisa menumpuk dan memperbesar risiko di masa depan, baik secara teknis (akumulasi technical debt), maupun secara bisnis (hilangnya kepercayaan pengguna). Oleh karena itu, penting bagi QA untuk memahami dan terlibat aktif dalam proses bug resolution, bukan hanya sebagai pencatat bug, tetapi sebagai mitra strategis dalam menjaga kualitas produk dari awal hingga akhir proses pengembangan.

Untuk membuka pembelajaran pada topik ini, berikut beberapa pertanyaan awal yang dapat membantu Digiers melihat gambaran besarnya.

Dalam dunia pengembangan perangkat lunak, istilah "bug" mengacu pada kesalahan atau kecacatan dalam sistem yang menyebabkan perangkat lunak tidak berfungsi sebagaimana mestinya. Namun, menemukan bug hanyalah langkah awal. Untuk menjaga kualitas produk, bug harus ditangani secara sistematis melalui melalui tahapan sistematis yang disebut siklus hidup bug (bug life cycle), yaitu serangkaian proses yang menggambarkan perjalanan sebuah bug dari pertama kali ditemukan hingga benar-benar terselesaikan dan ditutup.

Memahami siklus hidup bug penting bagi seluruh seluruh anggota tim, khususnya QA (Quality Assurance), karena QA terlibat di hampir setiap tahap proses ini. QA bukan hanya berperan sebagai "penemu bug", tetapi juga memastikan bug ditangani dengan jelas, tepat sasaran, dan tuntas. QA membantu mendeskripsikan masalah dengan detail, menyusun langkah reproduksi yang akurat, menetapkan tingkat keparahan bug, hingga memverifikasi hasil perbaikan oleh tim developer.

Tahapan Umum dalam Siklus Bug

Berikut adalah tahapan umum dalam siklus hidup bug:

1.    New / Open (Baru / Terbuka)
Saat QA atau pihak lain menemukan bug dan mencatatnya di sistem pelacakan (issue tracker), bug akan memiliki status awal sebagai "New" atau "Open". Pada tahap ini, QA menyusun laporan bug secara detai yang berisi: langkah-langkah reproduksi, hasil yang diharapkan dan aktual, tangkapan layar, hingga versi aplikasi dan perangkat yang digunakan. Tujuannya adalah agar developer bisa memahami konteks dan sumber masalah dengan cepat dan akurat.

2.    Assigned (Ditugaskan)
Setelah laporan bug masuk, biasanya Project Manager, Lead QA, atau Scrum Master akan meninjau laporan tersebut dan menetapkan siapa developer yang paling sesuai untuk menangani bug tersebut. Penugasan ini mempertimbangkan faktor seperti area tanggung jawab developer, tingkat kompleksitas, dan beban kerja yang sedang berlangsung. QA biasanya juga dilibatkan untuk memberi klarifikasi bila diperlukan.

3.    In Progress / In Development (Dalam Proses / Dalam Pengembangan)
Developer yang telah ditugaskan mulai menganalisis dan memperbaiki bug. Proses ini bisa berlangsung cepat atau lambat, tergantung dari jenis bug, kompleksitas logika yang terlibat, atau ketersediaan waktu dalam sprint. Di tahap ini, QA tidak tinggal diam. QA bisa menyiapkan test case atau skenario pengujian untuk pengujian ulang (retest) nanti, atau tetap berkomunikasi dengan developer untuk memberikan masukan tambahan, terutama untuk bug yang sulit direproduksi.

4.    Fixed / Resolved (Sudah Diperbaiki / Diselesaikan)
Setelah developer selesai melakukan perbaikan, bug akan diberi status “Fixed” atau “Resolved”. Namun, ini bukan berarti bug sudah selesai. QA tetap harus memverifikasi bahwa bug benar-benar telah diperbaiki. Dalam beberapa organisasi, status “Resolved” artinya developer merasa bug sudah selesai, tetapi masih perlu diverifikasi oleh QA sebelum bisa dianggap “Closed”. Dokumentasi atau catatan perubahan yang dilakukan oleh developer, seperti commit message, pull request, atau komentar dalam tiket juga sangat penting untuk membantu QA dalam memahami konteks perbaikan.

5.    Retest / QA Verification (Uji Ulang / Verifikasi QA)
QA kembali menguji fitur yang sebelumnya bermasalah untuk memastikan bahwa bug tersebut memang telah hilang dan tidak muncul lagi. Pengujian ulang dilakukan di lingkungan staging, QA, atau UAT (User Acceptance Testing), tergantung pada pipeline CI/CD yang digunakan oleh tim. Selain memverifikasi bahwa bug tidak lagi muncul, QA juga perlu memastikan tidak ada efek samping atau kerusakan baru (regression) yang muncul akibat perbaikan ini.

6.    Reopen (Dibuka Kembali)
Jika perbaikan tidak berhasil atau bug masih muncul, maka QA dapat mengubah status bug menjadi “Reopen”. Bug ini akan kembali masuk ke alur perbaikan, biasanya dengan penambahan catatan atau data baru untuk memperjelas kenapa perbaikan sebelumnya belum berhasil. Ini adalah salah satu tahap penting yang membutuhkan kolaborasi erat antara QA dan Developer untuk menghindari miskomunikasi dan menyelesaikan masalah secara tuntas.

7.    Closed (Ditutup)
Jika QA sudah memverifikasi bahwa bug sudah diperbaiki dengan baik dan tidak menyebabkan efek samping, maka bug dapat ditandai sebagai “Closed”. Status ini menandakan bahwa seluruh proses penanganan bug telah selesai. Bug yang ditutup tetap disimpan dalam sistem pelacakan sebagai arsip dan referensi di masa depan, terutama jika masalah serupa muncul lagi.

8.    Status Tambahan (Opsional): Deferred, Duplicate, Rejected
Dalam beberapa kasus, tidak semua bug langsung diperbaiki. Beberapa bug ditandai sebagai:

○      Deferred: Bug ditunda karena prioritas rendah atau keterbatasan sumber daya.

○      Duplicate: Bug serupa sudah pernah dilaporkan sebelumnya.

○      Rejected: Laporan bug tidak valid, tidak bisa direproduksi, atau bukan termasuk kategori bug.

Peran QA di Setiap Tahap

Seorang QA tidak hanya bertugas di awal (saat pelaporan) dan akhir (saat verifikasi), melainkan juga memiliki kontribusi sepanjang siklus dengan cara:

●      Mengidentifikasi bug secara akurat dan detail.

●      Berkomunikasi aktif dengan developer untuk klarifikasi masalah.

●      Membantu menetapkan severity dan prioritas.

●      Mendesain test case dan test scenario untuk retest.

●      Melakukan verifikasi terhadap perbaikan dan regresi.

●      Menjamin transparansi status bug dalam sistem pelacakan.

Dengan peran tersebut, QA menjadi penghubung antara kebutuhan pengguna, bisnis, dan tim teknis dalam memastikan kualitas produk.

Siklus Hidup Bug

Gambar 1.6.1 Siklus Hidup Bug

Pada praktiknya, siklus hidup bug tidak selalu bergerak lurus dari New ke Closed. Terkadang bug bisa bolak-balik antara status Fixed ↔ Reopen beberapa kali, terutama jika:

●      Masalah hanya diperbaiki sebagian.

●      Ada kesalahpahaman antara QA dan developer.

●      Bug muncul tergantung pada kondisi lingkungan atau data tertentu.

Severity vs. Priority

●      Severity (Tingkat Keparahan): Dampak bug terhadap sistem.

○      Critical: Menyebabkan crash atau hilangnya data.

○      Major: Mengganggu alur utama pengguna, tapi aplikasi masih berjalan.

○      Minor: Masalah kecil, tidak mengganggu fungsionalitas inti.

○      Trivial: Masalah visual atau kesalahan penulisan.

●      Priority (Tingkat Urgensi): Seberapa cepat bug harus ditangani. Biasanya ditentukan oleh PO atau tim manajemen berdasarkan:

○      Dampak terhadap bisnis.

○      Tenggat waktu rilis.

○      Beban kerja dan sumber daya.

Alat Pelacakan Bug (Bug Tracking Tools)

Beberapa tools populer yang digunakan untuk melacak siklus hidup bug, yaitu:

●      Jira: paling umum di tim Agile/Scrum, fleksibel dan bisa dikustomisasi.

●      Bugzilla: open-source dan banyak digunakan di proyek software open source.

●      Trello: sederhana dan visual, cocok untuk tim kecil atau freelance.

●      ClickUp, Notion, Asana: digunakan sebagai alternatif modern berbasis kolaborasi.

Bug Triage Meeting

Bug triage meeting adalah sesi berkala (misalnya seminggu sekali, tergantung kebutuhan) untuk meninjau dan memprioritaskan bug. Sesi ini dihadiri oleh QA, developer, PO, dan kadang customer support yang memiliki tujuan untuk:

●      Memastikan bug penting tidak terlewat.

●      Menyesuaikan prioritas dengan roadmap rilis.

●      Menghindari backlog bug yang menumpuk.

Bug Tidak Selalu Diperbaiki

Tidak semua bug harus diperbaiki saat itu juga. Beberapa bug bisa ditunda penanganannya karena alasan-alasan berikut:

●      Tidak berdampak signifikan pada pengguna.

●      Perbaikannya memerlukan waktu besar untuk hasilnya tidak signifikan.

●      Akan tertangani dalam refactor/rewrite besar nanti.

Bug Regression & Prevention

QA perlu berhati-hati terhadap regression bug, yaitu bug lama yang muncul kembali karena perubahan kode lain. Untuk mengantisipasinya, beberapa langkah berikut dapat dilakukan:

●      Menjaga test case regresi tetap up-to-date.

●      Menggunakan automated regression testing jika memungkinkan.

●      Menerapkan code review dan test coverage yang baik.

Kolaborasi Lintas Tim

Agar penanganan bug berjalan efektif, diperlukan komunikasi lintas fungsi antara QA dan berbagai peran terkait. Kolaborasi ini mencakup:

●      QA ↔ Developer: untuk debugging dan verifikasi.

●      QA ↔ PO: untuk eskalasi bug prioritas tinggi.

●      QA ↔ CS/UX: untuk mengonfirmasi keluhan pengguna atau dampaknya terhadap pengguna.

Dokumentasi yang Baik = Perbaikan yang Cepat

Laporan bug yang disusun dengan jelas dan lengkap dapat mempercepat proses analisis dan perbaikan oleh tim teknis. Beberapa elemen penting yang perlu dicantumkan dalam laporan bug antara lain:

●      Judul deskriptif (misal: "Voucher gagal diterapkan pada halaman checkout di iOS")

●      Langkah-langkah reproduksi yang konkret

●      Hasil aktual vs. hasil yang diharapkan

●      Environment (versi app, browser, OS, dsb)

●      Lampiran (screenshot, video, log)

Studi Kasus: Siklus Hidup Bug

1. Kasus 1: Bug pada Halaman Checkout E-Commerce

QA menemukan masalah bahwa pada proses checkout, di mana pengguna tidak dapat menyelesaikan pembelian jika menggunakan kode voucher tertentu. Temuan ini kemudian dilaporkan ke Jira dengan bukti langkah reproduksi.

Secara proses, berikut ini adalah alur penanganan bug berdasarkan status dalam bug life cycle:

●      New: QA melaporkan bug

●      Assigned: Developer frontend ditugaskan

●      In Progress: Developer mulai menganalisis dan menemukan masalah pada validasi JavaScript

●      Fixed: Perbaikan dilakukan dan lalu hasil perbaiki dikirim ke staging untuk diuji

●      Retest: QA melakukan pengujian ulang dan ternyata berhasil

●      Closed: QA menutup laporan bug, dengan catatan bahwa bug tidak muncul lagi di rilis berikutnya

2. Kasus 2: Bug UI pada Halaman Profil Dianggap “Deferred”

QA melaporkan bahwa ikon tombol di halaman profil sedikit terpotong ketika dibuka di jenis browser tertentu. Namun, setelah didiskusikan, tim product memutuskan bahwa bug ini bukan prioritas utama untuk sprint saat ini.

Oleh karena itu, bug tersebut diberi status Deferred (ditunda), yang artinya penanganannya akan dipertimbangkan kembali dalam perencanaan sprint mendatang.