Tips Menulis Bug Report Yang Baik
Ada yang mengatakan bahwa semua orang bisa menulis bug report, tapi tidak semua orang bisa menulis bug report yang baik.

Menulis bug report merupakan output penting dari proses testing yang dilakukan oleh Quality Assurance tester. Ada yang mengatakan bahwa semua orang bisa menuliskan bug report, akan tetapi cuma sedikit yang bisa menulis bug report dengan baik. Lalu, apa sih yang menjadi patokan sebuah bug report itu baik atau tidak?

Patokannya cukup sederhana kisanak, bug report yang baik adalah laporan yang efektif dan mudah untuk dikelola serta ditindaklanjuti oleh developer. Elemen penting lain yang perlu diperhatikan adalah bug report  harus terhindar dari penjelasan-penjelasan yang misleading (menyesatkan). 


Setelah mengetahui patokan utama bug report yang baik, kita perlu mengetahui struktur dari sebuah bug report. Sebenarnya struktur dari bug report secara garis besar mirip seperti struktur ketika kita menuliskan e-mail. Meskipun mirip, kisanak perlu untuk memperhatikan detail-detail dari struktur bug report


Struktur Bug Report


  1. Judul

Judul laporan harus straight to the point sehingga pembaca mengetahui langsung pokok permasalahan dalam sekali membaca. Quality Assurance tester perlu untuk menginformasikan bug yang ditemukan dalam pemaparan spesifik dan singkat. Beberapa hal ini perlu diperhatikan ketika menuliskan judul bug report:

a) Judul harus memuat informasi di mana bug ditemukan.

b) Harus bisa menggambarkan bug tanpa penjelasan panjang.
c) Setiap judul bug harus dibuat se-presisi mungkin.

Contoh penulisan judul: “Homepage: terjadi crash saat klik button home”.


  1. Deskripsi

Bagian deskripsi merupakan merupakan penjelasan lebih mendetail dari judul. Deskripsi harus memuat informasi serta fakta yang didapatkan Quality Assurance tester ketika melakukan proses testing. Untuk menuliskan deskripsi bug report yang baik, setidaknya kisanak perlu menjawab beberapa poin berikut:


a) Di mana lokasi bug berada?

b) Seperti apa kondisi sebelum bug muncul?

c) Seperti apa kondisi saat bug muncul?

d) Seperti apa kondisi setelah bug muncul?


Lebih detail lagi, deskripsi dari bug report yang baik seharusnya memuat beberapa elemen antara lain: step by step to reproduce bug, expected behaviour and actual behaviour, dan attachment. Mari kita bahas satu persatu maksud dari elemen-elemen tersebut


  1. Step by step to reproduce

Secara ringkas dan rinci, Quality Assurance tester perlu untuk menerangkan langkah-langkah yang kisanak lakukan untuk menemukan bug. Step by step akan memberikan gambaran yang jelas pada developer. Penjelasan ini juga akan memudahkan developer untuk melakukan reka ulang ketika memastikan validitas dari bug yang dilaporkan.


  1. Attachment

Attachment merupakan bagian dari bug report yang digunakan untuk memvisualisasikan bug. Attachment akan mempermudah penerima bug report untuk mengidentifikasi bug. Format file attachment yang paling umum digunakan untuk bug report adalah screenshot maupun video. Untuk mendukung penulisan bug report yang baik, ada beberapa hal yang perlu diperhatikan ketika hendak mencantumkan attachment antara lain:


i) Attachment merupakan upaya visualisasi step by step dari proses testing.
ii) Nama file attachment  memuat: nama project + judul bug. Hal ini akan memudahkan akses file attachment.


  1. Expected behaviour dan actual behaviour

Apabila proses penggunaan software tidak berjalan mulus, maka perlu untuk menuliskan expected behaviour dan actual behaviour. Expected behavior menjelaskan apa yang seharusnya terjadi ketika pengguna melakukan langkah-langkah yang tertulis di step by step. Sedangkan actual behavior adalah hasil yang didapatkan ketika step by step dijalankan oleh pengguna.


Informasi Tambahan


Setelah memahami struktur bug report, ada informasi tambahan yang perlu untuk diketahui agar penulisan bug report dapat lebih efektif. Hal ini terkait dengan  Bug Severity, bug priority dan juga percentage occur. Dengan mengetahui tiga poin tersebut dan menerapkannya di penulisan bug report, kisanak yang akan menuliskan informasi yang lebih detail kepada penirma laporan.


  1. Bug Severity

Quality Assurance tester perlu untuk menyampaikan aspek severity dari bug yang mereka temukan.  Bug severity merupakan klasifikasi untuk menentukan sebesar apa bug akan berdampak pada sistem. Semakin parah tingkat severity sebuah bug, maka bug tersebut akan semakin mempengaruhi jalannya software. Tingkat severity tinggi dapat membuat block bahkan crash pada software.


  1. Bug Priority

Setelah bug severity, ada bug priority. Klasifikasi priority akan menentukan seberapa penting bug itu harus segera diselesaikan. Semakin tinggi tingkat prioritas sebuah bug, maka bug tersebut harus segera untuk diselesaikan. 


  1. Percentage Occur

Percentage occur merupakan informasi tentang seberapa sering bug dapat direproduksi. Informasi ini penting untuk diketahui oleh penerima bug report. Jika persentase terjadinya bug mencapai 100%, maka bug report yang ditulis tanpa keterangan percentage occur tidak akan menimbulkan misleading. Sebaliknya, bug dengan percentage occur di bawah 100% perlu untuk memberikan keterangan percentage occur


Setelah mengetahui struktur dan informasi tambahan, ada beberapa poin-poin yang perlu kisanak ketahui sebelum menulis bug report. Penjelasan ini tidak lain adalah tips yang akan meningkatkan kualitas penulisan bug report.


Tips Meningkatkan Kualitas Bug Report


  1. Jelas dan ringkas

Kurang jelasnya laporan dapat membuat kesalahpahaman dan memperlambat proses development. Maka dari itu, perlu untuk memperhatikan apakah bug report yang kita buat sudah cukup mudah untuk dipahami.

Keringkasan sebuah laporan akan menjadi nilai tambah dari laporan yang dibuat oleh Quality Assurance tester. Jadi, laporan yang disajikan langsung menuju pokok permasalahan.


  1. Tidak menyudutkan developer

Tendensi penyampaian harus terlepas dari sentimen-sentimen yang akan merusak hubungan kerja. Maka dari itu perlu untuk memilih kata-kata yang pas ketika membuat laporan.

Quality Assurance tester juga tidak sepatutnya untuk memiliki asumsi yang buruk terhadap developer. Hal ini akan berimbas pada interaksi-interaksi kerja selanjutnya.

 

  1. Ingat tujuan penulisan bug

Bug report ditulis agar developer mengetahui secara jelas di mana bug tersebut terjadi dan bagaimana bug tersebut bisa terjadi. Jadi perlu untuk memberikan informasi yang detail mengenai hal-hal tersebut.


  1. Respon Cepat Jika Menemukan Bug

Apabila menemukan bug, Quality Assurance tester perlu untuk segera membuat laporan. Begitu juga dengan developer, mereka harus untuk bergegas menganalisa dan memperbaiki bug dari laporan yang mereka terima. Apabila penyampaian bug report dan respon penerima bug report lambat, hal tersebut akan berimbas pada timeline yang telah dibuat.


  1. Lakukan reproduksi bug tiga kali sebelum melaporkan

Setidaknya lakukan reproduce bug sebanyak tiga kali sebelum menulis laporan. Langkah ini akan memastikan laporan yang kisanak buat lebih valid. Beberapa bug perlu untuk diuji percentage occur-nya. Keterangan percentage occur adalah hal yang penting untuk diketahui developer, terlebih untuk bug yang persentase kemunculannya di bawah 100%. Tanpa keterangan lengkap, laporan bisa jadi membingungkan ketika dibaca oleh developer.


  1. Gunakan metode pengujian yang sama

Sering kali developer menggunakan rangkaian coding yang mirip untuk fitur-fitur serupa di sebuah software. Apabila kisanak menemukan bug di salah satu fitur, maka ada baiknya untuk melakukan testing di fitur-fitur serupa lainnya. Ada kemungkinan kisanak akan menemukan bug lain.


  1. Baca ulang bug report sebelum dikirim

Perlu untuk memastikan apakah bug yang hendak kisanak kirimkan telah ringkas, singkat dan padat akan informasi. Baca semua tulisan yang kisanak buat dari awal hingga akhir.


Setidaknya ini akan menghindarkan Quality Assurance tester untuk memberikan informasi yang ambigu. Karena laporan yang baik akan membuat Quality Assurance tester terbebas dari kewajiban untuk menuliskan ulang bug report.


Itu dia kisanak beberapa tips menulis bug report yang baik dari startup Jogja, Qatros Teknologi Nusantara. Harus diakui akan cukup merepotkan apabila harus membaca dan menulis laporan testing dengan manual tanpa bantuan tools apapun. Maka dari itu ada baiknya kisanak menggunakan alat bantu bug report. Salah satu alat bantu yang bisa kisanak digunakan adalah getdebug.

getdebug merupakan platform scenario dan bug collaboration tool untuk mempermudah kerja tim (QA, PM / owner, Dev). getdebug memberikan akses gratis bagi publik untuk melakukan melakukan testing sebanyak 1000 skenario. Di layanan gratis ini, getdebug mendukung kinerja tim user-nya dengan menyediakan slot gratis untuk unlimited PM / owner, unlimited dev, dan 1 user tambahan sebagai Quality Assurance.




Sign in to leave a comment
Klasifikasi Bug: Bug Severity dan Bug Priority
Klasifikasi merupakan upaya pengorganisiran yang mempermudah kita untuk menjangkau atau menyelesaikan masalah.