Ketika sebuah fungsi yang tidak berjalan sesuai sistem, artinya kita menemukan bug. Hal ini sangat wajar terjadi, terutama jika kita sedang berada pada tahapan development product ataupun tahapan testing.
Bug adalah kesalahan pada produk atau program software yang tidak berjalan sebagai mana mestinya. Bug juga dipahami sebagai kesalahan desain pada software, sehingga tidak mampu menjalankan sesuai perintah
Dalam mengatasi bug, terdapat siklus yang disebut sebagai Bug Life Cycle. Simak selengkapnya pengertian Bug Life Cycle, status & tahapan bug life cycle, beserta bug report yang dapat diunduh di akhir artikel!
Baca Juga: Perbedaan & Definisi Bug, Freeze, Error, Defect, Fault, Failure
Apa Itu Bug Life Cycle
Bug Life Cycle (BLC) adalah siklus yang terjadi pada bug sejak ditemukan sampai selesai ditangani. Sebagai QA engineer maupun software developer, penting untuk kita memahami Bug Life Cycle agar mempermudah komunikasi dan koordinasi tim dalam proses bug fixing.
Penerapan Bug Life Cycle di setiap perusahaan dapat berbeda-beda, tergantung dari kebutuhan bug yang perlu ditangani.
Bisa juga penerapan BLC tergantung dari preferensi peran yang mereview terlebih dulu. Contohnya, perusahaan A menugaskan QA untuk mereview terlebih dulu, sedangkan perusahaan B menugaskan developer sebagai reviewer yang pertama.
Bug yang ditemukan akan melewati beberapa tahapan dalam siklus ini, berikut adalah tahapan dasar dari Bug Life Cycle beserta statusnya.
Status dan Tahapan Bug Life Cycle
1. New
Ketika sebuah bug ditemukan, QA harus melaporkan dengan membuat bug report untuk di-submit ke Senior QA atau QA Lead sebagai project leader untuk kemudian divalidasi.
2. Review / Assigned
Pada tahap ini, project leader akan mereview bug yang sudah dilaporkan untuk divalidasi dan didelegasikan ke tim terkait. Sebelum di-assigned, ada 3 status yang akan terjadi pada tahap ini:
- Need review: Jika bug report kita belum valid, maka QA Lead akan mengembalikan report kita untuk direvisi & di-submit ulang
- Deferred: Berkaitan dengan testing scope, jika bug yang ditemukan di luar dari timeline scope yang sedang di-testing, maka bug report kita akan ditangguhkan dan diberi status Deferred. Contoh, di week ini scope testing kita ada di halaman login, tetapi bug yang kita temukan ada di payment process. Artinya bug report kita akan diberi status Deferred karena di luar dari scope testing, dan baru akan diproses sesuai timeline scope payment process.
- Duplicate: Jika bug report sudah pernah dilaporkan sebelumnya, maka akan statusnya akan menjadi Duplicate untuk menghindari laporan yang ganda.
- Rejected: Bug dianggap bukan bug dari developer, sehingga berstatus Rejected
- Not Bug: Bug tidak berdampak pada fungsionalitas aplikasi, sehingga diberi status Not Bug. Jika bug report yang Binarian lakukan bersifat valid maka tahapan dan status yang akan dilalui valid > in scope > not duplicate. Sehingga bug report kamu bisa lanjut ke tahap berikutnya yaitu fixing.
3. Fixed
setelah bug sudah selesai diperbaiki oleh developer dan siap dites ulang, maka statusnya akan menjadi fixed. Tim developer dalam tahap ini sudah merubah coding untuk memperbaiki bug. Sehingga hasil perbaikannya akan ditempatkan kembali di environment QA, setelah lolos retest.
4. Retest
pada tahap ini QA akan melakukan test ulang pada bug yang telah diperbaiki. Ada 3 kemungkinan status yang akan terjadi pada tahap ini:
- Reopen: Jika bug masih terjadi, maka akan diberi status Reopen dan akan diperbaiki lagi oleh tim developer
- Verified: setelah QA melakukan testing dan bug sudah tidak ditemukan lagi, maka akan diberi status Verified
- Closed: setelah testing selesai dan bug benar-benar tidak ada pada product / software, maka QA akan memberikan status Closed yang artinya bug sudah diperbaiki, teruji, dan disetujui.
Apa Itu Bug Report
Bug report adalah laporan dengan format tertentu yang berisi informasi tentang bug dan hal yang perlu diperbaiki dalam produk.
Bug report digunakan sebagai dokumentasi tim QA untuk melaporkan ke project leader yang berkaitan dengan produk yang sedang dikembangkan.
Fungsi Bug Report adalah
- Untuk mengetahui tahapan bug yang ditemukan
- Untuk kepentingan bug tracing (pemantauan) dan melihat riwayat bug
- Untuk mengetahui apakah bug yang ditemukan sudah pernah dilaporkan atau belum
- Sebagai sumber dokumentasi bagi QA untuk mengetahui perlu tidaknya untuk tes ulang
- Untuk mengkonfirmasi apakah bug masih terjadi atau tidak
- Menjadi panduan bagi developer untuk melakukan bug fixing
Ada 2 cara dalam menyusun bug report, menyesuaikan dengan metode testing yang dilakukan. Jika kamu melakukan uji coba dengan cara manual testing, maka bug report juga disusun secara manual. Sebaliknya jika kamu melakukan uji coba dengan automation testing, maka bug report bisa di-generate secara otomatis dengan coding.
Masing-masing perusahaan punya format yang berbeda, tergantung kebutuhan. Bahasa yang paling sering digunakan dalam bug report adalah Bahasa Inggris. Kita akan membahas cara membuat bug report dengan cara manual.
Baca Juga: Perbedaan QA Manual Testing dan QA Automation Testing
Cara Membuat Bug Report & Template Bug Report
Agar kamu dapat memahami gambaran bug report manual, Sabrina menyediakan format berupa template bug report manual yang bisa diunduh secara gratis pada kolom akhir artikel.
- Tanggal: isi tanggal sesuai kapan bug ditemukan
- Judul: isi bagian judul dengan informatif dan efektif. Informatif artinya dapat menunjukan letak / scope bug yang terjadi, efektif artinya informasi yang kita tulis tetap jelas dan ringkas. Beberapa perusahaan juga mempunyai prefix / awalan tertentu yang disepakati oleh tim. (Lihat contoh penulisan judul pada template)
- Deskripsi: bagian ini berisi informasi tambahan seputar bug yang ditemukan, contoh informasinya bisa seperti menjelaskan trigger yang memicu bug; menjelaskan step penemuan bug, kondisi seharusnya, dan kondisi yang terjadi pada software; menjelaskan merk / seri dan/ firmware dari device yang digunakan; menjelaskan jika bug terjadi di device tertentu dan tidak terjadi di device tertentu (compatible issue).
- Steps: bagian ini berisi detail tahapan ditemukannya bagian yang mengalami bug. Bagian steps harus diisi detail supaya membantu developer dalam memperbaiki bug.
- Attachment: bagian ini berisi bukti screenshot maupun bukti recording untuk memberikan gambaran lebih detail tentang letak bug yang dimaksud.
- Severity: severity adalah dampak bug yang bisa dihasilkan jika tidak segera diatasi, pilih salah satu severity bug mulai dari critical, major, medium, minor.
- Priority: untuk menentukan apakah bug ini harus segera diatasi atau bisa ditunda, ditentukan dari status priority pada bagian ini. Pilih salah satu antara high, middle, low.
- Label: penggunaan label digunakan untuk membantu mempercepat identifikasi bug oleh developer dan stakeholder lainnya yang perlu membaca report. Umumnya label terdiri dari Platform yang digunakan, Tipe Report, dan Environment.
- Reporter & Assignee: reporter dapat diisi sesuai nama kita sebagai tester / QA engineer yang melaporkan bug report. Sedangkan assignee dapat diisi nama penerima report kita sesuai alur kerja bug fixing (bisa ditujukan ke project leader, SQA, atau QA lead yang bertanggung jawab)
.png)
