Defect Management & Bug Report
Site: DILo Game Academy
Course: Game Tester Course
Book: Defect Management & Bug Report
Printed by: Nadhif Yonda Raditya
Date: Saturday, 19 February 2022, 2:32 PM
Table of contents
1. Defect Management
2. Bug Report
1. Defect Management
Defect
Management
Apa itu Defect atau Bug?
Defect atau bug di dalam software
adalah perbedaan atau penyimpangan dari ekspektasi yang
diharapkan. Ekspektasi
ini biasanya mengacu pada hal-hal general seperti requirement bisnis atau end
usernya dan untuk teknis bisa dalam bentuk functionality error atau hasil diluar
ekspektasi yang tidak
sesuai dengan requirement yang sesungguhnya.
Defect Management
Pada umumnya, defect management
dapat diartikan sebagai proses menemukan bug dan melakukan
fixing. Bug akan
selalu terus ada di dalam proses development. Ini disebabkan oleh proses
development terbilang cukup kompleks, sementara tim harus bekerja dengan
deadline yang singkat.
Ditambah biasanya tim dev tentu tidak akan punya waktu
untuk memikirkan bagaimana untuk
menghindari bug. Disinilah dimana proses
development perlu adanya proses khusus yang membantu
menemukan bug dan
melakukan fixing.
Berdasarkan gambar diatas Jika
disederhanakan prosesnya kurang lebih akan menjadi:
1. Hunting
Disini adalah tahap dimana tester
akan mencari bug sebanyak mungkin dan kemudian melaporkannya
kepada tim
developer.
Developer bisa menerima atau
menolak bug yang dilaporkan jika issue yang dilaporkan dianggap
bukan bug.
2. Classifying
a. Severity
Severity menentukan sejauh mana
bug tertentu dapat membuat dampak pada aplikasi atau sistem.
Setelah bug ditemukan, bug perlu diklasifikasikan tingkat severitynya oleh QA.
Severity ini akan
membantu tim yang bersangkutan dalam memprioritaskan issue
yang krusial.
Tingkat severity biasanya terdiri dari :
-
Critical
Issue yang terjadi menyebabkan sistem benar-benar berhenti & tidak bisa
melakukan tindakan lain
setelahnya (show stopper). Misal adanya crash
setelah menjalankan fungsi tertentu
-
Major:
Issue yang terjadi akibat penyimpangan yang sangat jauh dari requirements yang
ada.
Misalnya User mendapatkan 2 item ketika membeli barang, padahal seharusnya
menurut requirement
user harusnya mendapatkan 1 item saja.
-
Minor[AS3] [AK4] :
Issue yang tidak ada dampak pada fungsi, tetapi masih merupakan bug yang valid
yang harus
diperbaiki.
Misalnya permasalahan UI yang tidak terlalu signifikan, atau typo-typo
Sebenarnya tidak ada aturan yang pasti untuk ini, tiap organisasi bisa saja
punya kriterianya sendiri
utk severitynya. Misal ada yang ingin lebih detail
dengan menambahkan severity moderate, trivial,
cosmetics, dll.
b. Priority
Priority menentukan sesegera apa
suatu bug harus di fix. Pihak yang memiliki wewenang untuk
menentukan priority
bervariasi di setiap organisasi, tetapi pada umumnya project manager / produser
yang berwenang untuk menentukan prioritynya karena ia yang lebih mengerti soal
schedule
projectnya.
Tingkatan priority biasanya terdiri dari:
-
High
-
Medium
-
Low
Tips dalam menentukan priority
bisa merujuk pada gambar dibawah ini
c. Severity
vs Priority
Untuk perbedaan yang lebih jelas
antara Severity & Priority, ada di tabel berikut
Priority Severity
-
Defect Severity is
defined as the degree
-
Defect Priority has
defined the order in
of impact that a defect has on the operation of
which the developer should resolve a defect
the
product
-
Severity is categorized
into five types
-
Priority is categorized
into three types o
Critical
o
Low o
Major
o
Medium o
Moderate
o
High o
Minor
o
Cosmetic
-
Severity is associated
with
-
Priority is associated
with scheduling
functionality or standards
-
Priority indicates how
soon the bug -
Severity indicates the
seriousness of the
should be fixed defect on the product functionality
-
Priority of defects is
decided in -
QA determines the
severity level of the
consultation with the manager/client defect
-
Priority is driven by
business value -
Severity is driven by
functionality
-
Its value is subjective
and can change
-
Its value is objective
and less likely to
over a period of time depending on the change
change
in the project
situation
-
High priority and low
severity status
-
High severity and low
priority status
indicates, defect have to be fixed on
indicates defect have to be fixed but not on
immediate bases but
does not affect the
immediate bases
application
-
Priority status is based
on customer -
Severity status is based
on the technical
requirements aspect of the product
3. Fixing
Di tahap ini, developer akan
menentukan apa yang ingin di fix, kapan melakukan fixnya & ketika
telah
selesai melakukan fixing developer akan melaporkan kembali kepada QA untuk
diverifikasi
apakah bug yang sebelumnya sudah terselesaikan atau belum
1. Verifying
Di tahap ini, QA akan melakukan
verifikasi terhadap issue yang sudah di fix oleh developer.
Seandainya masih
ada issue, maka QA akan melaporkan kembali ke pada developer.
2. Closing
Di tahap ini, seandainya issue
yang sebelumnya sudah solved, maka issue akan di tutup oleh QA
dengan
melaporkan hasil akhirnya.
Keseluruhan langkah-langkah
diatas jika digambarkan sebagai diagram, kurang lebih akan menjadi
seperti ini
2. Bug Report
11. Bug Report
“The better
your bug report, the quicker the problem can get solved.”
Inti dari sebuah bug report yang
baik adalah, report tersebut dapat membuat pembacanya (e.g
produser,
programmer) memahami “why” suatu permasalahan terjadi dan memberikan
informasi
bagaimana cara untuk reproduce atau menduplikasi permasalahan
tersebut ke dalam sistem mereka.
Bug report yang baik pada
dasarnya terdiri dari:
-
Summary / Title
Coba bandingkan antara summary
yang berisi “Bug pada login” atau “Masalah pada login” dengan
“Error 500 ketika
login di OS Android 10, tetapi iOS tidak ada masalah”. Sebagai seorang
programmer yang hendak mencari tahu masalah & melakukan fixing, tentu
summary yang terakhir
lebih mudah untuk dipahami. Pastikan informasikan yang diberikan singkat,
padat & jelas.
-
Description
Bagian ini berisi deskripsi lebih
detail dari permasalahan yang ada. Sebaiknya jangan langsung lompat
ke inti
permasalahan, tetapi jelaskan bagaimana dari awal sampai menemukan bug tersebut
dan apa
ekspektasi yang seharusnya terjadi. Akan lebih baik lagi, jelaskan juga
“why a problem is a problem”
untuk membantu developer dalam mendapatkan
gambaran seberapa serius bugnya, seberapa urgent
bugnya hingga dapat memberikan
gambaran tentang masalah lain yang mungkin terjadi terkait dengan
bug tersebut.
Elemen
description ini beberapa diantaranya adalah :
a.
Step to Reproduce :
Langkah-langkah yang diperlukan untuk mereproduksi bug yang terjadi dari awal
hingga bug itu
terjadi.
b.
Expected Result
Hal yang diharapkan terjadi berdasarkan requirement atau yang sewajarnya
terjadi
c.
Actual Result
Hal yang justru sesungguhnya terjadi
d.
Extra Information
Information tambahan ini dapat berupa gambar, video, error / crash log, tingkat severity, tingkat
occurrence (seberapa
pasti bug tersebut terjadi), dll. Dapat disesuaikan dengan issue yang dibuat
untuk memberikan informasi yang lebih detail agar lebih mudah untuk dipahami
Contoh jika keseluruhan hal
diatas dibuat menjadi panduan untuk membuat bug report, maka kurang
lebih akan
menjadi seperti:
Summary/Title
User dapat login dengan menggunakan password yang salah
Details
Terdapat security risk yang cukup besar, karena fungsi untuk mengecek validitas
password tidak
berfungsi
Step to Reproduce
1. Buka
[Link]/login
2. Masukkan
Username yang valid di kolom Username
3. Masukkan
Password yang tidak valid di kolom Password
4. Tekan
Enter
Expected Result
Login gagal & akan muncul notifikasi “Username atau Password salah”
Actual Result
Login berhasil, dan membawa ke halaman profile dimana user bisa mengedit
informasi yang ada
Additional Information:
- Video: <link>