Bug Reporting

Start from Basic Topic, right ? :)
Post Reply
User avatar
risdian
Posts: 1
Joined: Tue Jan 28, 2020 3:58 pm

Bug Reporting

Post by risdian »

Hai, Sobat IDSTB

Sebagai seorang software tester yang baik, tentu kita pernah kan diminta untuk melaporkan kejanggalan yang terjadi pada aplikasi yang kita uji? :D Bahasa kerennya, kita melakukan "Bug Reporting". Apabila diterjemahkan secara harfiah ke dalam Bahasa Indonesia menjadi "Pelaporan Serangga"? :lol:

Fun Fact about Software Bug
Mungkin ada yang penasaran, kenapa suatu hal yang tidak semestinya ada di sebuah aplikasi MALAH disebut sebagai "serangga"? Pada kenyataannya, istilah ini pertama kali digunakan di tahun 1947. Pada saat itu, Universitas Harvard sedang menjalankan sebuah program komputer dan tiba-tiba saja perangkat lunak tersebut mengalami error/failure. Usut punya usut, mereka menemukan suatu hal yang tidak semestinya di mesin komputer mereka.

Image

Betul, mereka menemukan seekor serangga yang terhimpit di mesin komputer mereka. Hal ini juga yang menyebabkan istilah "Bug" menjadi populer. Garis bawahnya, suatu hal yang menyebabkan aplikasi tidak bekerja semestinya dapat disebut sebagai software bug.

Then, What About Bug Report?
Ketika sebuah software bug terjadi pada aplikasi, hal tersebut perlu didokumentasikan. "Lho, kenapa?" Karena nantinya dokumentasi ini akan ditujukan kepada tim ybs. supaya bisa diperbaiki. Terdengar mudah, tapi pada faktanya tidak sesederhana itu.

Image

Melalui topik kali ini, saya mencoba merangkum beberapa informasi yang biasanya dibutuhkan ketika kita mendokumentasikan sebuah bug report.

1. Bug Title
Sebuah bug report yang baik tentu akan lebih mudah diingat dari penulisan judul laporan yang tepat. Bila judul laporan terlalu panjang, tim ybs. akan butuh waktu sedikit lebih banyak untuk membaca judulnya itu sendiri. Usahakan sebuah laporan hanya mencakup satu isu saja (bila ada lebih dari satu isu di sebuah pelaporan, lebih baik buat pelaporan lainnya yang terpisah).

2. Bug Severity
Umumnya, ada 4 tingkat untuk mendefinisikan seberapa "parahnya" sebuah bug yang terjadi di aplikasi.
  • Critical
Bug ini perlu diperbaiki sesegera mungkin. Hal ini dikarenakan aplikasi tidak dapat melanjutkan fungsionalitas utama sebuah sistem (crash, freeze, blocked), yang artinya pengguna tidak dapat melakukan hal apa pun karena adanya bug ini.

  • High
Terjadi di fungsionalitas utama juga, tapi pengguna dapat mencari cara lain (workaround) pada aplikasi.

  • Medium
Bug ini tidak terjadi di fungsionalitas utama, tapi lebih ke fungsionalitas tambahan pada sebuah sistem.

  • Low
Lebih cenderung ke arah kosmetik. Misal, salah penulisan ejaan atau warna yang ditampilkan tidak sesuai.


3. Test Environment
Bila ingin mencantumkan informasi mengenai perangkat lunak dan perangkat keras yang digunakan, silahkan masukkan di bagian ini.

4. Actual Result
Keadaan yang sesungguhnya terjadi pada sebuah aplikasi. Bisa menggunakan kalimat yang digunakan di Bug Title, tapi detil lebih spesifiknya dapat diceritakan di bagian ini.

5. Expected Result
Keadaan yang diharapkan ada di sebuah aplikasi. Lebih menekankan keadaan yang akan terjadi bila aplikasi tersebut digunakan dalam keadaan normal.

6. Steps to Reproduce
Instruksi tentang bagaimana sebuah bug bisa muncul pada sebuah aplikasi. Fokus utama dalam hal ini adalah menyediakan informasi yang akurat/spesifik kepada tim ybs.

7. Evidence
Apabila dibutuhkan, bukti tambahan dapat dilampirkan pada sebuah laporan. Misal, screenshot/video/crash log.

Semoga bermanfaat,
Risdian

Post Reply