TESTING 4

IV. Bug Tracking Database

IV.1. Formal Bug Tracking System
 Bug tracking database dapat mengkomunikasikan bug dengan jelas.
 Dengan memberikan standard penulisan bug dapat menjelaskan lebih baik dibandingkan dengan email form biasa
 Dengan database dapat diberikan nomor urut secara otomatis, sehingga pada saat kita akan merujuk ke bug tertentu dapat menggunakan nomor urut tersebut.
 Dapat diberikan prioritas urutan dengan mudah untuk memperbaiki bug.
 Dapat mengelola pelacakan bug melalui sklus hidupnya dari laporan awal hingga resolusi akhir.
 Sebagai bug progress sklus hidupnya memudahkan bagi developers, testers dan manajer dalam dalam mempelajari informasi baru.

IV.2. Failure Description
 Keterangan tentang failure dari suatu program, failure description ini merupakan alat untuk mengkomunikasikan bug dari tester pada programmer
 Penulisan Failure Description
* Jelaskan tahapan bagaimana caranya untuk mendapatkan bug tersebut
* Penulisan harus singkat dan jelas, tidak bertele-tele dan tidak terlalu singkat sehingga sulit di mengerti














Contoh Laporan Bug yang Baik










Contoh Laporan Bug yang Terlampau Singkat

IV.3. Konstruksi Awal Database
 Minimal suatu bug tracking database harus menyimpan diskripsi failure, summary, langkah-langkah reproduksi dan isolasinya.
 Dengan identifikasi informasinya menggunakan sequential nomor Id, nama proyek pembuat laporan dan tanggal laporan yang dimasukan.


Tabel Dasar untuk Bug Tracking Database


Tampilan pada bug tracking database menggunakan bug entry form


Laporan Detail Bug

Laporan Summary Bug


IV.4. Pengelompokan Bug
 Severity adalah akibat dari kesalahan didalam sistem yang sedang dilakukan pengetesan, dapat ditandakan berdasarkan nomor yang ada dibawah ini :
1. Data hilang, kerusakan hardware
2. Fungsi yang tidak dapat berjalan dengan baik, dan tidak ada cara lain
3. Fungsi yang tidak dapat berjalan dengan baik, dan mempunyai cara lain untuk menjalankanya
4. Fungsi atau fitur yang hilang sebagian
5. Kesalahan kosmetik
 Prioritas perlu diberikan dalam memperbaiki suatu error, dan prioritas ini tidak selalu sama dengan severity. Pemberian prioritas adalah sebagai berikut :
1. Highest priority. The system is practically unusable with this bug
2. High priority. The bug will have a serious impact on the company’s ability to sell and maintain this system
3. Medium priority. The company will lose some money if this bug is in the system, but it might be more important to meet the schedule. Fix after release if it is not fixed before
4. Low priority. Don’t delay the release, but do fix this problem afterward
5. Lowest priority. Fix as time and resources allow

IV.5. Penambahan Informasi Dinamik
IV.5.1. Pengelolaan Bug Life Cycles
















Bug State dan Transisi

 Review, setelah tester melakukan pengetesan bug report di review oleh test manager
 Rejected, bila bug report tidak jelas atau kurang informasi maka bug report tersebut ditolak untuk di perbaiki oleh si tester
 Open, jika bug report sudah di review dan diterima maka bug report tersebut open untuk di lihat oleh developer
 Assigned, jika developer menerima bug report tersebut, kemudian menunjuk developer untuk memperbaiki bug tersebut
 Test, setelah diperbaiki oleh developer maka di test kembali dan dilakukan regression testing.
 Reopened, jika perbaikannya masih ada yang salah maka bug di buka kembali agar dapat diperbaiki oleh developer
 Closed, jika bug sudah selesai di perbaiki status bug sudah selesai maka di tutup
 Deffered, bila bug tersebut dianggap tidak perlu diperbaiki sekarang karena mempunyai prioritas yang rendah, atau digunakan untuk versi yang akan datang

IV.5.2. Pelacakan Perubahan Status
 Setiap bug melewati perubahan status, direkam didalam status log sehingga tester, developers dan para manager dapat melacak bug yang ada.
 Penulisan untuk bug dilakukan untuk kejadian yang mengubah status bug saja, bukan setiap kejadian seperti pada buku harian

IV.6. Informasi tentang bug
 Agar dapat menyelesaikan masalah bug dengan baik diperlukan adanya suatu pengukuran yang baik.
 Didalam pelacakan database, perlu ditambahkan beberapa informasi seperti close date, resolution, dan root cause.
 Perlu juga adanya pengelompokan dari sistem, agar kita dapat mengetahui di modul yang mana yang masih banyak mengandung bug.


Lokasi Bug dan Skedul test untuk SpeedyWriter


Opened/closed chart untuk SpeedyWriter



Endless Bug Discovery


Closure period for SpeedyWriter


SpeedyWriter root cause breakdown

SpeedyWriter subsystem breakdown