Dokumen ini membahas manajemen bug dan cacat dalam pengembangan perangkat lunak, termasuk proses analisis cacat untuk meningkatkan kualitas dan efisiensi. Klasifikasi cacat menurut tingkat keparahan dan prioritas sangat penting untuk manajemen risiko. Siklus hidup bug mencakup tahap-tahap dari pelaporan hingga perbaikan, dengan penekanan pada pentingnya dokumentasi yang jelas dan prosedur kolaboratif dalam tim pengujian.

1. 1
Bug Management
• Defect Management
• Benefit of Defect Analysis
• Bugs and Root Causes
• Levels of Importance to Bug
• Bug Life Cycle
• Bug Report
• Steps for Better Bug Reports
• Managing Bug Tracking
• Besides the supply of information on the level of quality of software and systems, one of
the main objectives of the tests is to identify defects so that they are processed –
corrected or evaluated – before the software or the systemis delivered to customers. This
implies identifying and processing defects, as well as checking their correction.
• Defects can be classified according to several criteria: the impact on users (often called
criticality), the necessary effort to correct the defect, the component where this defect is
initially present, etc. Defect classification enables us to order them according to various
criteria and to take measures in order to avoid repeated reporting of already discovered
defects.
Introduction to Defect
• Selain penyediaan informasi mengenai tingkat kualitas perangkat lunak dan sistem, salah
satu tujuan utama dari tes ini adalah untuk mengidentifikasi cacat sehingga mereka diproses
- diperbaiki atau dievaluasi - sebelum perangkat lunak atau sistem dikirimkan ke pelanggan.
Ini berarti mengidentifikasi dan memproses cacat, serta memeriksa koreksinya. • Kerusakan
dapat diklasifikasikanberdasarkan beberapa kriteria: dampak pada pengguna (sering disebut
kekritisan), upaya yang diperlukan untuk memperbaiki cacat, komponen di mana cacat ini
awalnya ada, dll. Klasifikasi cacat memungkinkan kita untuk memesannya sesuai dengan
berbagai kriteria dan untuk mengambil langkah-langkah untuk menghindari pelaporan cacat
yang sudah ditemukan berulang kali.
Sub Topics

2. 2
1. Comparison to requirements and specifications provided for the
software design. Requirements and specifications should be testable
and comprise sufficientinformationtodetermine the level of qualityof
the actual results.Thismethoddoesnotalwaysenableaccurate testing,
because the options chosen by developers in case of ambiguities or
imprecisionscandifferfromthose chosenbythe tester.There willthen
be the creation of defects, which will be considered as “works as
designed” and as “a feature, not a bug” without any added value or
information;
2. Comparison with a previous version of the program or even other
competitor software, etc.
1. Perbandingan dengan persyaratan dan spesifikasi yang disediakan untuk desain
perangkat lunak. Persyaratan dan spesifikasi harus dapat diuji dan terdiri dari
informasi yang cukup untuk menentukan tingkat kualitas hasil aktual. Metode ini
tidak selalu memungkinkan pengujian yang akurat, karena opsi yang dipilih oleh
pengembang dalam hal ambiguitas atau ketidaktepatan dapat berbeda dari yang
dipilih oleh tester. Maka akan ada penciptaan cacat, yang akan dianggap sebagai
"berfungsi seperti yang dirancang" dan sebagai "fitur, bukan bug" tanpa nilai
tambah atau informasi;
2. Membandingkan dengan versi program sebelumnya atau bahkan perangkat
lunak pesaing lainnya, dll.
1. Structure: tests deliberately carried out while taking notes enable us to
find more easily the first indices of a defect;
2. Reproduction: the reproducibility of an anomaly is a necessaryattribute to
ensure its correction;
3. Isolation: once the defect is reproduced, it is important to isolate the
phases leading to its occurrence. Where possiblelimit the number of steps
necessaryto reproduce the defect.A defect including sevenstages ormore
is generally difficult to read and its correction will thus be delayed;
4. Generalizing: once the defect is isolated, we need to determine whether it
can be generalized. This includes the detection of other defects of a similar
structure in other modules of the software;
Defect Identification
Defect Reports Components
1. Struktur: tes yang sengaja dilakukan saat mencatat memungkinkan
kita menemukan lebih mudah indeks cacat pertama;
2. Reproduksi: reproduksibilitas anomali adalah atribut yang diperlukan
untuk memastikan koreksi;
3. Isolasi: begitu cacat direproduksi, penting untuk mengisolasi fase-fase
yang menyebabkannya terjadi. Bila memungkinkan batasi jumlah
langkah yang diperlukan untuk mereproduksi cacat. Cacat termasuk
tujuh tahap atau lebih umumnya sulit dibaca dan koreksinya akan
tertunda;
4. Generalisasi: setelah cacat diisolasi, kita perlu menentukan apakah itu
bisa digeneralisasi. Ini termasuk deteksi cacat lain dari struktur yang
serupa di modul perangkat lunak lain;

3. 3
5. Comparing: determining whether the defect has occurred for the first time
in this version of the application or whether it was already present (but
undetected) in previous versions;
6. Summarizing: the title of the defect (or its summary) is critical and must
show how it can affect customers;
7. Condensing: reducing the sizeofthe defectreport so as not to bore readers
and reducing the number of acronyms so that it remains readable;
8. Ambiguity: avoiding any ambiguity is important, in order not to be vague
or subject to misinterpretation;
9. Neutrality: the anomaly report must be neutral and not be perceived as an
attack against developers;
10. Review: once the defect has been written, it should be reread by another
tester.
5. Membandingkan: menentukan apakah cacat telah terjadi untuk pertama
kalinya dalam versi aplikasi ini atau apakah sudah ada (tetapi tidak terdeteksi) di
versi sebelumnya;
6. Meringkas: judul cacat (atau rangkumannya) sangat penting dan harus
menunjukkan bagaimana hal itu dapat mempengaruhi pelanggan;
7. Kondensasi: mengurangi ukuran laporan cacat agar tidak membosankan
pembaca dan mengurangi jumlah akronim sehingga tetap dapat dibaca;
8. Ambiguitas: menghindari ambiguitas apapun adalahpenting, agartidak kabur
atau tunduk pada salah tafsir;
9. Netralitas: laporan anomali harus netral dan tidak dianggap sebagai serangan
terhadap pengembang;
10. Ulasan: setelah cacat telah ditulis, itu harus dibaca kembali oleh penguji lain.
Benefit of Defect Analysis
Argumentation
about Defect Analysis
• Defectanalysis/preventionprocesses helptoreduce thecostsof developing
and maintaining software by reducing the number of defects that require
our attention in both review and execution-based testing activities.
• Defect analysis/prevention processes help to improve software quality.If
we identitythe cause of aclass of defectsandchange our processsothat it
doesnotreoccur,oursoftware shouldbe lessdefectivewithrespecttothat
class of defects and more able to meet the customer’s requirements.
• If our software containsfewerdefects,thisreducesthe total numberof
problemswe mustlookfor;the sheervolume of problemswe needto
addressmaybe significantlysmaller.
• Analisis cacat / proses pencegahan membantu mengurangi biaya pengembangan
dan pemeliharaan perangkat lunak dengan mengurangi jumlah cacat yang
membutuhkan perhatian kita dalam kegiatan pengujian dan pengujian berbasis
eksekusi. • Analisis cacat / proses pencegahan membantu meningkatkan kualitas
perangkat lunak. Jika kami mengidentifikasi penyebab kelas cacat dan mengubah
proses kami agartidak terulang kembali, perangkat lunak kami harus kurang cacat
sehubungan dengan kelas cacat tersebut dan lebih mampu memenuhi persyaratan
pelanggan. • Jika perangkat lunak kami mengandung lebih sedikit cacat, ini
mengurangi jumlah total masalah yang harus kita cari; volume masalah yang kita
perlu atasi mungkin jauh lebih kecil.

4. 4
• Defect analysis/prevention processes provide a framework for overall
process improvement activities. When we know the cause of a defect, we
identifyaspecificareaof ourprocessthatneedswork.Improvementsmade
in this area usually produce readily visible benefits. Defect analysis/
prevention activities not only help to fine-tune an organizations’ current
process and practices, but also support the identification and
implementationof newmethodsandtoolssothatcurrentprocesscontinues
to evolve and comes closer to being optimized.
• Defect analysis/prevention activities encourage interaction between a
diverse number of staff members, for example, project managers,
developers, testers, and SQA staff, The close interrelationships between
specialized group activities and the quality of internal and external
deliverables becomes more apparent.
• Analisis cacat / proses pencegahan menyediakan kerangka kerja untuk kegiatan
peningkatan proses secara keseluruhan. Ketika kita mengetahui penyebab cacat,
kita mengidentifikasi area spesifik dari proses kita yang perlu dikerjakan. Perbaikan
yang dilakukan di bidang ini biasanya menghasilkan manfaat yang mudah terlihat.
Analisis cacat / kegiatan pencegahan tidak hanya membantu menyempurnakan
proses dan praktik organisasi saat ini, tetapi juga mendukung identifikasi dan
implementasi metode dan alat baru sehingga proses saat ini terus berkembang dan
semakin dekat untuk dioptimalkan.
• Analisis cacat / kegiatan pencegahan mendorong interaksi antara beragam
anggota staf, misalnya, manajer proyek, pengembang, penguji, dan staf SQA,
Keterkaitan yang erat antara kegiatan kelompok khusus dan kualitas hasil internal
dan eksternal menjadi lebih jelas.
Benefits of Defect Analysis and Prevention Processes

5. 5
Bugs and Root Causes • An anomaly occurs when a tester observes an unexpected
behavior. If the test environment and the tester’s actions were
correct, this anomaly indicates either a system failure or a test
failure. The failure arises from a bug in either the system or the
test. The bug comes from an error committed by a software or
hardware engineer (while creating the system under test) or a
test engineer (while creating the test system). That error is the
root cause.
• Usually, the aim of performing a root cause analysis isn’t to
determine the exact error and how it happened. Other than
flogging some hapless engineer, you can’t do much with such
information. Instead, root cause analysis categorizes bugs into
a taxonomy.
• Anomali terjadi ketika penguji mengamati perilaku yang tidak terduga. Jika lingkungan
pengujian dan tindakan penguji benar, anomali ini mengindikasikan kegagalan sistem atau
kegagalanpengujian.Kegagalanmuncul dari bug di sistematau tes. Bug berasaldari kesalahan
yang dilakukan oleh insinyur perangkat lunak atau perangkat keras (saat membuat sistem
yang sedang diuji) atau insinyur uji (saat membuat sistem pengujian). Kesalahan itu adalah
penyebab utama. • Biasanya, tujuan melakukan analisis akar penyebab bukan untuk
menentukan kesalahanyang tepat dan bagaimana halitu terjadi. Selain mencambuk beberapa
insinyur yang malang, Anda tidak dapat berbuat banyak dengan informasi tersebut. Alih-alih,
analisis akar penyebab mengelompokkan bug ke dalam taksonomi.

6. 6
Levels of Importance to Bug
Risk
Priority
Number
(RPN)
Severity Priority
Mechanism to Assign Levels of
Importance to Bugs
• By severity, means the impact, immediateor delayed, of a bug on the
system under test, regardless of the likelihood of occurrence under end-
user conditions or the effect such a bug would have on users. You can use
the same scale used for failure mode and effect analysis (FMEA:
1. Loss of data, hardware damage, or a safety issue
2. Loss of functionality with no workaround
3. Loss of functionality with a workaround
4. Partial loss of functionality
5. Cosmetic or trivial
• Berdasarkantingkatkeparahannya,berarti dampak,langsungatau tertunda,dari
bug padasistemyangdiuji,terlepasdari kemungkinanterjadinyadi bawahkondisi
penggunaakhiratau efekbugtersebutpadapengguna.Andadapatmenggunakan
skalayang sama yangdigunakanuntukmode kegagalandananalisisefek(FMEA:
1. Kehilangandata,kerusakanperangkatkeras,ataumasalahkeamanan
2. Hilangnyafungsionalitastanpasolusi
3. Hilangnyafungsionalitasdengansolusi
4. Hilangnyasebagianfungsi
5. Kosmetikatausepele
Severity

7. 7
• You use priority to capture the elements of importance not
considered in severity, such as the likelihood of occurrence in actual
customer use and the subsequent impact on the target customer.
When determining priority, you can also consider whether this kind
of bug is prohibited by regulation or agreement, what kinds of
customers are affected, and the cost to the company if the affected
customers take their business elsewhere because of the bug. Again,
you can use a scale like the priority scale used in the FMEA:
1. Complete loss of systemvalue
2. Unacceptable loss of systemvalue
3. Possibly acceptable reduction in systemvalue
4. Acceptable reduction in systemvalue
5. Negligible reduction in systemvalue
• Anda menggunakan prioritas untuk menangkap unsur-unsur penting
yang tidak dipertimbangkan dalam tingkat keparahan, seperti
kemungkinan terjadinya penggunaan pelanggan aktual dan dampak
selanjutnya pada pelanggan sasaran. Saat menentukan prioritas, Anda
juga dapat mempertimbangkan apakah jenis bug ini dilarang oleh
peraturan atau perjanjian, jenis pelanggan apa yang terpengaruh, dan
biaya bagi perusahaan jika pelanggan yang terpengaruh membawa
bisnis mereka ke tempat lain karena bug tersebut. Sekali lagi, Anda
dapat menggunakan skala seperti skala prioritas yang digunakan dalam
FMEA:
1. Kehilangan total nilai sistem
2. Kehilangan nilai sistem yang tidak dapat diterima
3. Pengurangan yang mungkin diterima dalam nilai sistem
4. Penurunan nilai sistem yang dapat diterima
5. Pengurangan nilai sistem yang dapat diabaikan
Priority
Risk Priority Number (RPN)
for the Bug
• You can multiply severity by priority to
calculate a risk priority number (RPN) for the
bug. Using this approach, the RPN can range
from 1 (an extremely dangerous bug) to 25 (a
completely trivial bug).
• Anda dapat mengalikan keparahan dengan prioritas untuk
menghitung angka prioritas risiko (RPN) untuk bug. Dengan
menggunakan pendekatan ini, RPN dapat berkisar dari 1 (bug yang
sangat berbahaya) hingga 25 (bug yang sepenuhnya sepele).

8. 8
Bug Life Cycle
States in Managing
Bug Life Cycles
• Review. When a tester enters a new bug report in the bug-tracking database, the bug-tracking
database holdsitforreviewbeforeitbecomesvisibleoutsidethe testteam.Ifnon-testerscanreport
bugsdirectlyintothe system,thenthe managersof those non-testersshoulddeterminethe review
process for those non-tester bug reports.
• Rejected.If the reviewerdecidesthatareportneedssignificantrework— eithermore researchand
informationorimprovedwording—the reviewerrejectsthereport.Thiseffectivelysendsthereport
backto the tester,whocanthensubmitarevisedreportforanotherreview.The appropriateproject
team members can also reject a bug report after approval by the reviewer.
• Ulasan. Ketika seorang tester memasuki laporan bug baru di database pelacakan bug, database
pelacakan bug menyimpannya untuk ditinjau sebelum menjadi terlihat di luar tim pengujian. Jika non-
penguji dapat melaporkan bug langsung ke sistem, maka manajer non-penguji tersebut harus
menentukan proses peninjauan untuk laporan bug non-penguji tersebut.
• Rejected. Jika peninjau memutuskan bahwa suatu laporan membutuhkan pengerjaan ulang yang
signifikan- baikpenelitiandaninformasi lebihlanjutataukata-katayangdiperbaiki - peninjaumenolak
laporan.Ini secaraefektif mengirimkanlaporankembalike penguji,yangkemudiandapatmengirimkan
laporan yang telah direvisi untukpeninjauan lain. Anggota tim proyek yang tepat juga dapat menolak
laporan bug setelah disetujui oleh reviewer.

9. 9
• Previousfigure showsthe statesinbuglife cycle andthe flowsbetween
them. Terminal states— in other words, states in which a bug report’s
life cycle might terminate and the bug report become legitimately
inactive with no further action required or expected— are shown with
heavy lines.
• Typical flowsshownwithsolidlinesandatypical flowswithdottedlines.
Any time a bug report traverses an atypical flow, some degree of
inefficiency has occurred, which you as a test manager can and should
measure.
• Open.If the testerhas fullycharacterizedandisolatedthe problem,the
revieweropensthereport,makingitvisibletothe worldasaknownbug.
• Gambar sebelumnya menunjukkan status dalam siklus hidup bug dan aliran di
antara mereka. Status terminal — dengan kata lain, status di mana siklus hidup
laporan bug mungkin berakhir dan laporan bug menjadi tidak aktif secara sah
tanpa tindakan lebih lanjut yang diperlukan atau diharapkan — ditunjukkan
dengan garis-garis yang berat. • Aliran tipikal ditunjukkan dengan garis padat dan
aliran atipikal dengan garis putus-putus. Setiap kali laporan bug melintasi aliran
atipikal, beberapa tingkat inefisiensi telah terjadi, yang Anda dan manajer tes
dapat dan harus ukur. • Buka. Jikatester telah sepenuhnya mengkarakterisasi dan
mengisolasi masalah, pengulas membuka laporan, membuatnya terlihat oleh
dunia sebagai bug yang dikenal.
• Assigned. The appropriate project team members assign it to the
appropriate development manager, who in turn assigns the bug to a
particular developer for repair.
• Test. Once development provides a fix for the problem, it enters a test
state. The bug fix comes to the test organization for confirmation testing
(which ensures that the proposed fix completely resolves the bug as
reported) andregressiontesting(whichaddressesthe questionof whether
the fix has introduced new problems as a side effect).
• Reopened. If the fix failsconfirmation testing, the tester reopens the bug
report.If the fix passesconfirmationtestingbutfailsregressiontesting,the
tester opens a new bug report.
• Ditugaskan. Anggota tim proyek yang tepat menugaskannya kepada manajer
pengembangan yang sesuai, yang pada gilirannya menugaskan bug tersebut ke
pengembang tertentu untuk diperbaiki.
•Uji. Setelah pengembangan memberikan perbaikan untuk masalah, itu
memasuki kondisi uji. Perbaikan bug datang ke organisasi pengujian untuk
pengujian konfirmasi (yang memastikan bahwa perbaikan yang diusulkan
sepenuhnya menyelesaikan bug seperti yang dilaporkan) dan pengujian regresi
(yang membahas pertanyaan apakah perbaikan telah menimbulkan masalahbaru
sebagai efek samping).
• Dibuka kembali. Jika perbaikan gagal dalam pengujian konfirmasi, tester
membuka kembali laporan bug. Jika perbaikan melewati pengujian konfirmasi
tetapi gagal pengujian regresi, tester membuka laporan bug baru.

10. 10
• Closed. If the fix passes confirmation testing, the tester closes the bug
report.
• Deferred. If appropriate project team members decide that the problem is
real but choose either to assign a low priority to the bug or to schedule the
fixfor asubsequent release,the bug report is deferred. Note that the project
team can defer a bug at any point in its life cycle.
• Cancelled. If appropriate project team members decide that the problem is
not real, but rather is a false positive, the bug report is cancelled. Note that
the project team can cancel a bug at any point in its life cycle.
• Tutup. Jika perbaikan melewati pengujian konfirmasi, tester
menutup laporan bug.
• Tangguhan. Jika anggota tim proyek yang tepat memutuskan
bahwa masalahnya adalah nyata tetapi memilih untuk
menetapkan prioritas rendah untuk bug atau untuk
menjadwalkan perbaikan untuk rilis berikutnya, laporan bug
ditangguhkan. Perhatikan bahwa tim proyek dapat menunda
bug kapan saja dalam siklus hidupnya.
• Dibatalkan. Jika anggota tim proyek yang tepat memutuskan
bahwa masalahnya tidak nyata, tetapi lebih merupakan false
positive, laporan bug dibatalkan. Perhatikan bahwa tim proyek
dapat membatalkan bug kapan saja dalam siklus hidupnya.
Bug Report
Example of Good Bug Report
• The previous bug report contains three basic sections: summary, steps to reproduce, and
isolation.
• The summary is a one- or two-sentence description of the bug, emphasizing its impact on the
customeror the systemuser. The summary tellsmanagers,developers,andotherreaderswhy
they should care about the problem.
– The sentence,‘‘Ihad troublewithscreenresolutions’’isalousysummary;the sentence,
‘‘Setting screen resolution to 800 by 1024 renders the screen unreadable’’ is much
better.A succinct,hard-hittingsummaryhooksthereaderandputsalabelonthe report.
Consider it your one chance to make a first impression.
• Laporan bug sebelumnyaberisitigabagiandasar:ringkasan,langkah-langkahuntukmereproduksi,dan
isolasi. • Ringkasan adalah deskripsi satu atau dua kalimat dari bug, menekankan dampaknya pada
pelanggan atau pengguna sistem.Ringkasanini memberi tahu manajer, pengembang,dan pembaca lain
mengapamerekaharuspedulidenganmasalahtersebut.- Kalimatnya,‘‘Sayamengalamimasalahdengan
resolusi layar ’adalah ringkasan yang buruk; kalimatnya, ‘‘ Mengatur resolusi layar ke 800 x 1024
menjadikan layar tidak dapat dibaca ’jauh lebih baik. Ringkasan yang ringkas dan keras mengaitkan
pembacadanmemberi labelpadalaporan.Anggaplahinisatu-satunyakesempatanAndauntukmembuat
kesan pertama.

11. 11
• The steps to reproduce provide a precise description of how to repeat the
failure.Formostbugs,youcanwrite downasequence of stepsthatre-create
the problem. Be concise yet complete, unambiguous, and accurate. This
information is critical for developers, who use your report as a guide to
duplicate the problem as a first step to debugging it. As a test manager and
as a consultant,I have heardmany teamsof programmerscomplainbitterly
aboutthe poorjobthe testteamwasdoingintermsof bugreporting. Inmost
cases, their complaints centered around the poor quality of the steps to
reproduce.
• Langkah-langkah untuk mereproduksi memberikan deskripsi yang tepat tentang cara
mengulang kegagalan. Untuk sebagian besar bug, Anda dapat menuliskan urutan langkah
yang menciptakan kembali masalah. Bersikap singkat namun lengkap, tidak ambigu,dan
akurat. Informasi ini sangatpentinguntukpengembang,yangmenggunakanlaporanAnda
sebagai panduanuntukmenduplikasi masalahsebagai langkahpertamauntukmen-debug
itu. Sebagai manajer pengujian dan sebagai konsultan, saya telah mendengar banyak tim
pemrogram mengeluh tentang pekerjaan yang buruk yang dilakukan oleh tim pengujian
dalam hal pelaporan bug. Dalam kebanyakan kasus, keluhan mereka berpusat pada
buruknya kualitas langkah-langkah untuk mereproduksi.
• Isolation refers to the results and information the tester gathered
to confirm that the bug is a real problem and to identify those
factors that affect the bug’s manifestation. What variations or
permutations did the tester try in order to influence the behavior?
For example, if the problem involves reading the CD-ROMdrive on
DataRocket, what happens when theCD-ROMis on a different SCSI
ID? Did the tester check the SCSI termination? If SpeedyWriter
can’t print to alaserprinter, can it print to an inkjet? Good isolation
draws a bounding box around a bug. Documenting the isolation
steps performed will assure the programmers and the project
team that the tester isn’t simply tossing an anomaly over the wall,
but is instead reporting a well-characterized problem.
• Isolasi mengacu pada hasil dan informasi yang dikumpulkan oleh penguji untuk
mengkonfirmasi bahwa bug adalah masalah nyata dan untuk mengidentifikasi faktor-
faktor yang mempengaruhi manifestasi bug. Variasi atau permutasi apa yang coba
dilakukan penguji untuk memengaruhi perilaku? Misalnya, jika masalahnya melibatkan
membaca CD-ROM drive pada DataRocket, apa yang terjadi ketika CD-ROM pada ID
SCSI yang berbeda? Apakah tester memeriksa penghentian SCSI? Jika SpeedyWriter
tidak dapat mencetak ke printer laser,dapatkah iamencetak ke inkjet? Isolasiyang baik
menarik kotak pembatas di sekitar bug. Mendokumentasikan langkah-langkah isolasi
yang dilakukan akan meyakinkan para programmer dan tim proyek bahwa tester tidak
hanya melemparkan anomali di atas dinding, tetapi malah melaporkan masalah yang
ditandai dengan baik.
Example
of Incomplete Bug Report

12. 12
Example
of Confusing Bug Report
Design for a Basic
Bug-Tracking Database

13. 13
A Bug Detail Report A Bug Detail Report
with Dynamic Information

14. 14
Steps for Better Bug Reports
• Some number of bug reports will always be irreproducible or contested.
Some bugs exhibit symptoms only intermittently, under obscure or
extreme conditions. In some cases, such as systemcrashes and database
corruption, the symptoms of the bug often destroy the information
needed to track down the bug. Inconsistencies between test
environments and the programmers’ systems sometimes lead
programmers to respond, ‘‘works fine on my system’’.
• On some projects without clear requirements, there can be reasonable
differences of opinion over what is correct behavior under certain test
conditions. Sometimes testers misinterpret test results and report bugs
when the real problem is bad test procedures, bad test data, or incorrect
test cases.
• Sejumlah laporan bug akan selalu tidak dapat diproduksi kembali atau
diperebutkan. Beberapa bug hanya menunjukkan gejala sesekali, dalam kondisi
yang tidak jelas atau ekstrem. Dalam beberapa kasus, seperti kerusakan sistem
dan kerusakan basis data, gejala bug sering kali menghancurkan informasi yang
diperlukan untuk melacak bug. Ketidakkonsistenan antara lingkungan pengujian
dan sistem pemrogram terkadang membuat pemrogram merespons, "bekerja
dengan baik di sistem saya".
• Pada beberapa proyek tanpa persyaratan yang jelas, mungkin ada perbedaan
pendapat yang masuk akal tentang apa perilaku yang benar dalam kondisi
pengujian tertentu. Terkadang penguji salah mengartikan hasil tes dan
melaporkan bug ketika masalah sebenarnya adalah prosedur pengujian yang
buruk, data pengujian yang buruk, atau kasus pengujian yang salah.
Environment
in Dealing with Bug Reports
1. Structure: Test thoughtfully and carefully, whether you’re using reactive
techniques, following scripted manual tests, or running automated tests.
2. Reproduce:My usual rule of thumbistotrytoreproduce the failurethree times.
If the problemisintermittent,reportthe rate of occurrence;forexample,one in
three tries, two in three tries, and so forth.
3. Isolate: See if you can identifyvariables— for example, configuration changes,
workflow, data sets— that might change the symptoms of the bug.
1. Struktur: Tes dengan cermat dan hati-hati, apakah Anda
menggunakan teknik reaktif, mengikuti tes manual yang ditulis, atau
menjalankan tes otomatis.
2. Reproduksi: Aturan praktis saya yang biasa adalah mencoba
mereproduksi kegagalan tiga kali. Jika masalahnya intermiten, laporkan
laju kejadiannya; misalnya, satu dari tiga percobaan, dua dari tiga
percobaan, dan sebagainya.
3. Isolate: Lihat apakah Anda dapat mengidentifikasi variabel —
misalnya, perubahan konfigurasi, alur kerja, kumpulan data — yang
mungkin mengubah gejala bug.
Ten Steps
for Better Bug Reports

15. 15
4. Generalize:Lookforplacesthatthe bug’ssymptomsmightoccurin
other parts of the system, using different data, and so forth,
especially where more severe symptoms might exist.
5. Compare: Review the results of running similar tests, especially if
you’re repeating a test run previously.
6. Summarize: Write a short sentence that relates the symptom
observedtothe customers’orusers’experiencesof quality,keeping
inmindthatinmanybug reviewortriage meetings,the summaryis
the only part of the bug report that is read.
7. Condense: Trim any unnecessary information, especially
extraneous test steps.
4. Generalisasi: Cari tempat-tempat dimana gejala bug mungkin terjadi di
bagian lain dari sistem, menggunakan data yang berbeda, dan sebagainya,
terutama di mana gejala yang lebih parah mungkin ada.
5. Bandingkan: Tinjau hasil menjalankan tes serupa, terutama jika Anda
mengulangi tes sebelumnya.
6. Ringkas: Tuliskan kalimat pendek yang menghubungkan gejala yang
diamati dengan pengalaman kualitas pelanggan atau pengguna, ingatlah
bahwa dalam banyak ulasan bug atau rapat triase, ringkasan adalah satu-
satunya bagian dari laporan bug yang dibaca.
7. Mengembun: Potong informasi yang tidak perlu, terutama langkah-
langkah tes asing.
8. Be clear: Use clear words, avoiding especially words that have
multiple distinctor contradictorymeanings;forexample,‘‘The ship
had a bowon itsbow,’’and‘‘Properoversightpreventsoversights,’’
respectively.
9. Neutralize: Express yourself impartially, making statements of fact
about the bug and itssymptomsand avoiding hyperbole,humor,or
sarcasm. Remember, you never know who’ll end up reading your
bug report.
10. Review:Have atleastone peer,ideallyanexperiencedtestengineer
or the test manager, read the bug report before you submit it.
8. Bersikap jernih: Gunakan kata-kata yang jelas, hindari kata-kata yang memiliki
banyak makna berbeda atau kontradiktif; misalnya, ‘‘ Kapal memiliki busur di
haluannya, ’’ dan ‘overs Pengawasan yang tepat mencegah pengawasan,’ secara
berurutan.
9. Netralkan: Ekspresikan diri Anda secara tidak memihak, membuat pernyataan
fakta tentang bug dan gejalanya dan menghindari hiperbola, humor, atau
sarkasme.Ingat,Andatidakpernahtahusiapayangakhirnyamembacalaporanbug
Anda.
10. Tinjau: Minta setidaknya satu rekan sejawat, idealnya seorang insinyur
pengujianberpengalamanataumanajerpengujian,membacalaporanbugsebelum
Anda mengirimkannya.

16. 16
Managing Bug Tracking
• Here, however, we should briefly examine political issues that are
specificallyrelatedtobugdata.Fromthe mostadversarial pointof view,for
example, you can see every bug report as an attack on a developer. You
probablydon’t— andcertainlyshouldn’t — intendtooffend,butithelpsto
rememberthatbug data ispotentiallyembarrassingandsubjecttomisuse.
Candor and honestyare critical in gatheringcleanbug data, but developers
mightdistortthe factsif theythinkyoumightusethe datatoslamthemwith
the bug reports. Think of the detailed bug information your database
capturesas a loadedgun:an effective tool inthe righthandsand usedwith
caution, but a dangerous implement of mayhem if it’s treated carelessly.
• Namun, di sini, kita harus memeriksa secara singkat isu-isu politik yang secara
spesifik terkait dengan data bug. Dari sudut pandang paling bermusuhan, misalnya,
Anda dapat melihat setiap laporan bug sebagai serangan terhadap pengembang.
Anda mungkin tidak - dan tentu saja tidak boleh - bermaksud untuk menyinggung,
tetapi perlu diingat bahwa data bug berpotensi memalukan dan dapat
disalahgunakan. Keterusterangan dan kejujuran sangat penting dalam
mengumpulkan data bug bersih, tetapi pengembang mungkin mendistorsi fakta jika
mereka berpikir Anda mungkin menggunakan data untuk membanting mereka
dengan laporan bug. Pikirkan informasi bug terperinci yang ditangkap oleh database
Anda sebagai senjata yang dimuat: alat yang efektif di tangan kanan dan digunakan
dengan hati-hati, tetapi alat berbahaya yang berbahaya jika diperlakukan dengan
sembarangan.
• Some situations are irretrievable. Developers who are convinced
that a written bug report is one step removed from a written
warning in their personnel files probably will never trust you. Most
developers, though, approach testing with an open mind. They
understand that testing can provide a useful service to them in
helping them fix bugs and deliver a better product. How do you
keep the trust and support of these developers?
– Don’t take bugs personally, and don’t become emotional
about them.
– Submit only quality bug reports: a succinct summary, clear
steps to reproduce, evidence of significant isolation work,
accuracy in classification information, and a conservative
estimate in terms of priority and severity. Also try to avoid
cheap shot bug reports that can seemlike carping.
– Be willing to discuss bug reports with an open mind.
– If developers want you to change something in your bug-
reporting process, be open to their suggestions.
Don’t Fail to Build Trust
• Beberapasituasi tidakdapat diperbaiki.Pengembangyangyakinbahwalaporanbug tertulis
adalahsatu langkahdihapusdari peringatantertulisdalamfilepersonel merekamungkintidak
akanpernahmempercayai Anda.Namun,sebagianbesarpengembangmelakukanpendekatan
pengujian dengan pikiran terbuka. Mereka memahami bahwa pengujian dapat memberikan
layanan yang bermanfaat bagi mereka dalam membantu mereka memperbaiki bug dan
memberikan produk yang lebih baik. Bagaimana Anda menjaga kepercayaan dan dukungan
pengembang ini?
- Jangan mengambil bug secara pribadi, dan jangan menjadi emosional tentang mereka.
- Kirimkan hanya laporan bug kualitas: ringkasan ringkas, langkah-langkah jelas untuk
mereproduksi, bukti pekerjaan isolasi yang signifikan, akurasi dalam informasi klasifikasi, dan
perkiraankonservatifdalamhal prioritasdantingkatkeparahan.Cobajugauntukmenghindari
laporan bug penembakan murah yang bisa terlihat seperti carping.
- Bersedia mendiskusikan laporan bug dengan pikiran terbuka.
- Jika pengembang ingin Anda mengubah sesuatu dalam proses pelaporanbug Anda, terbuka
untuk saran mereka.

17. 17
• The test manager needs to ensure that testers identify,
reproduce, and isolate bugs. It’s also part of the job to track
the bugs to conclusion and to deliver crisp bug status
summaries to senior and executive management. These roles
differ, though, from managing bug fixes.
• If you, as an outsider, make it your job to nag developers about
when a specific bug will be fixed or to pester the development
manager about how slow the bug fix process is,you are setting
yourself up for a highly antagonistic situation. Reporting,
tracking, re-testing, and summarizing bugs are your worries.
Whether any particular bug gets fixed, how it gets fixed, and
when it gets fixed are someone else’s concerns.
• Manajer tes perlu memastikan bahwa penguji mengidentifikasi, mereproduksi, dan
mengisolasi bug. Itu juga bagian dari pekerjaan untuk melacak bug sampai pada
kesimpulan dan untuk memberikan ringkasan status bug yang tajam kepada
manajemen senior dan eksekutif. Peran ini berbeda, dari mengelola perbaikan bug.
• Jika Anda, sebagai orang luar, menjadikannya tugas Anda untuk mengomel pada
pengembang tentang kapan bug tertentu akan diperbaiki atau mengganggu manajer
pengembangan tentang betapa lambatnya proses perbaikan bug, Anda mengatur diri
sendiri untuk situasi yang sangat antagonis. Melaporkan, melacak, menguji ulang, dan
meringkas bug adalahkekhawatiran Anda. Apakah bug tertentu diperbaiki, bagaimana
diperbaiki, dan ketika diperbaiki adalah kekhawatiran orang lain.
• It is a bad idea to create and distribute reports that make
individuals look bad. There’s probably no fasterwayto guarantee
that you will have trouble getting estimated fix dates out of
people than to produce a report that points out every failure to
meet such estimated dates. Creating reports that show how
many bug fixes resulted in reopened rather than closed bugs,
grouped and totaled by developer, is another express laneto bad
relationships. Again, managing the developers is the
development manager’s job, not yours. No matter how useful a
particular report seems, make sure that it doesn’t bash
individuals.
• Merupakan ide yang buruk untuk membuat dan mendistribusikan laporan
yang membuat individu terlihat buruk. Mungkin tidak ada carayang lebih cepat
untuk menjamin bahwa Anda akan mengalami kesulitan dalam mendapatkan
estimasi tanggal perbaikan orang daripada membuat laporan yang
menunjukkan setiap kegagalan untuk memenuhi perkiraan tanggal tersebut.
Membuat laporan yang menunjukkan berapa banyak perbaikan bug yang
menghasilkan bug yang dibuka kembali dan tidak ditutup, dikelompokkan dan
dijumlahkan oleh pengembang, adalahjalurcepat untuk hubungan yang buruk.
Sekali lagi, mengelola pengembang adalah tugas manajer pengembangan,
bukan milik Anda. Tidak peduli seberapa berguna laporan tertentu, pastikan itu
tidak merusak individu
Don’t Make Individuals
Look Bad

18. 18
• Challengingbugscropuponnearlyeveryproject.The mostvexing
are those that involve questions about correct behavior, prairie
dog bugs that pop up only when they feel like it, and bugs that
cause a tug-of-war over priority.
• Bug yang menantang muncul di hampir setiap proyek. Yang paling menjengkelkan
adalah yang melibatkan pertanyaan tentang perilaku yang benar, serangga anjing
padang rumput yang muncul hanya ketika mereka menginginkannya, dan serangga
yang menyebabkan tarik ulur prioritas.
Sticky Wickets
• Although a perfect development project provides you with clear and
unambiguous information about correct systembehavior in the form of
requirements and specifications, you will seldom have such good
fortune. Many projects have only informal specifications, and the
requirements can be scattered around in emails, product road maps,
and sales materials. In such cases, disagreements can arise between
development and test over whether a particular bug is in fact correct
system behavior.
• How should you settle these differences? Begin by discussing the
situation with the developers, their manager, and your testers. Most of
these disagreements arise from miscommunication. Before making a
major issue out of it, confirm that all the parties are clear on what the
alleged bug is and why your team is concerned.
Bug or Feature?
• Meskipun proyek pengembangan yang sempurna memberi Anda informasi
yang jelas dan tidak ambigu tentang perilaku sistem yang benar dalam bentuk
persyaratan dan spesifikasi, Anda jarang akan mendapatkan nasib baik. Banyak
proyek hanya memiliki spesifikasi informal, dan persyaratannya dapat tersebar
di email, peta jalan produk, dan materi penjualan. Dalam kasus seperti itu,
ketidaksepakatan dapat muncul antara pengembangan dan pengujian apakah
bug tertentu sebenarnya perilaku sistem yang benar.
• Bagaimana seharusnya Anda menyelesaikan perbedaan-perbedaan ini?
Mulailah dengan membahas situasi dengan pengembang, manajer mereka, dan
penguji Anda. Sebagian besar ketidaksepakatan ini timbul dari miskomunikasi.
Sebelum mengeluarkan masalah besar, konfirmasikan bahwa semua pihak
sudah mengetahui dengan jelas apa dugaan bug tersebut dan mengapa tim
Anda khawatir.

19. 19
• The challenge with irreproducible bugs comes in two flavors.
– First, some bugs simply refuse to reproduce their symptoms
consistently. This is especially the case in system testing, in which
complex combinations of conditions are required to re-create
problems. Sometimes these types of failures occur in clusters. If you
see a bug three timesinone dayand thendon’tsee itfor a week,has
it disappeared, or is it just hiding? Tempting as it is to dismiss this
problem, be sure to write up these bugs. Random, intermittent
failures— especially ones that result in system crashes or any other
data loss— can have a significant effect on customers.
– The second category of irreproducible bugs involves problems that
seem to disappear with new revisions of the system, although no
specific fix was made for them. I refer to these as ‘‘bugs fixed by
accident.’’Youwill findthatmore bugsare fixedbyaccidentthanyou
expect, but that fewer are fixed by accident than some project
Pollyannas suggest. If the bug is an elusive one, you might want to
keepthe bug report active until you’re convinced it’s actually gone.
• Tantangan dengan bug yang tidak dapat diproduksi kembali datang dalam dua
rasa.
- Pertama, beberapa bug menolak untuk mereproduksi gejala mereka secara
konsisten. Ini terutama terjadi dalampengujian sistem, di mana kombinasi kondisi
yang kompleks diperlukan untuk menciptakan kembali masalah. Kadang-kadang
jenis kegagalan ini terjadi dalam kelompok. Jika Anda melihat bug tiga kali dalam
satu hari dan kemudian tidak melihatnya selamaseminggu, apakah iamenghilang,
atau hanya bersembunyi? Karena tergoda untuk menghilangkan masalah ini,
pastikan untuk menulis bug ini. Kegagalan acak dan terputus-putus — terutama
yang mengakibatkan crash sistematau kehilangan data lainnya — dapat memiliki
efek signifikan pada pelanggan.
- Kategori kedua bug yang tidak dapat diperbaiki melibatkan masalah yang
tampaknya hilang dengan revisibaru sistem,meskipun tidak ada perbaikan khusus
yang dibuat untuk mereka. Saya menyebut ini sebagai ‘‘bug yang diperbaiki secara
tidak sengaja. ’Anda akan menemukan bahwa lebih banyak bug yang diperbaiki
secara tidak sengaja daripada yang Anda harapkan, tetapi lebih sedikit yang
diperbaiki secara tidak sengaja daripada yang disarankan oleh beberapa proyek
Pollyannas. Jika bug itu sulit dipahami, Anda mungkin ingin tetap mengaktifkan
laporan bug sampai Anda yakin itu benar-benar hilang.
• While bug severity is easy to quantify, priority is not. Developing
consensus on priority is often difficult. What do you do when bugs are
assignedalowpriority?Bugsthat will notbe fixedshouldbe deferred.If
you don’t keep the active bug list short, people will start to ignore it.
However, there’s a real risk that some deferred bugs will come back to
hauntyou. What if a deferredbugpopsup inthe fieldasa critical issue?
Is thata testescape?Notif myteamfounditandthendeferreditonthe
advice or insistence of the project manager.
• After you institute a bug-tracking system, including the database and
metricsdiscussedhere,youwill findyourself the keeperof keyindicators
of project status. Fairness and accuracy should be your watchwords in
this role.
• Meskipun tingkat keparahan bug mudah dikuantifikasi, prioritasnya tidak.
Mengembangkan konsensus tentang prioritas seringkali sulit. Apa yang Anda lakukan
ketikabugdiberi prioritasrendah?Bugyangtidak akan diperbaikiharusditangguhkan.
Jika Anda tidak membuat daftar bug aktif singkat, orang akan mulai mengabaikannya.
Namun, ada risiko nyata bahwa beberapa bug yang ditangguhkan akan kembali
menghantui Anda.Bagaimanajikabug yang ditangguhkanmuncul di lapangansebagai
masalahkritis?Apakahituteslolos?Tidakjikatimsaya menemukannyadankemudian
menunda saran atau desakan manajer proyek.
• Setelah Anda membuat sistem pelacakan bug, termasuk basis data dan metrik yang
dibahasdi sini,AndaakanmenemukandiriAndasebagai penjagaindikatorutamastatus
proyek. Keadilan dan akurasi harus menjadi semboyan Anda dalam peran ini.
Deferring Trivia
or Creating Test Escapes?
Irreproducible Bug