Sebagai seorang software tester yang baik, tentu kita pernah kan diminta untuk melaporkan kejanggalan yang terjadi pada aplikasi yang kita uji? Bahasa kerennya, kita melakukan "Bug Reporting". Apabila diterjemahkan secara harfiah ke dalam Bahasa Indonesia menjadi "Pelaporan Serangga"?
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.
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.
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
- High
- Medium
- Low
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