Rangkuman dari bagian “Defects” (tutorial 22-24)

<links removed by admin as requested by link owner>

Bug harus berisi informasi sebagai berikut

Defect_ID – nomor identifikasi yang unik untuk defect.

defect Uraian – deskripsi rinci bug  termasuk informasi tentang modul yang defect ditemukan.

Versi – Versi aplikasi defect yang ditemukan.

Langkah – langkah Detail bersama dengan screenshot dengan yang pengembang dapat mereproduksi bug yang ada.

Dibesarkan Tanggal – Tanggal ketika defect dinaikkan

Referensi yang digunakan untuk Menyediakan dan mengacu pada dokumen-dokumen seperti. persyaratan, desain, arsitektur atau mungkin bahkan screenshot dari kesalahan tersebut untuk membantu memahami defect.
Terdeteksi Dengan – Nama / ID dari tester yang mengangkat defect
Status – Status defect , lebih lanjut tentang ini nanti
Tetap oleh – Nama / ID dari pengembang yang tetap itu
Ditutup Tanggal – Tanggal ketika defect ditutup
Sebuah laporan bug sampel untuk sebuah referensi. Ini terpisah, biasanya  laporan bug juga akan mencakup Keparahan, yang menggambarkan dampak defect pada aplikasi dan Prioritas yang berkaitan dengan urgensi untuk memperbaiki defect.  Keparahan & Prioritas bisa Tinggi / Menengah / Rendah berdasarkan pengaruh & urgensi di mana defect harus tetap masing-masing  Sebuah defect bisa memiliki tingkat keparahan yang sangat rendah tetapi prioritas tinggi, Misalnya jika ada kesalahan dalam teks logo aplikasi reservasi penerbangan, beratnya rendah karena yang bisa diperbaiki sangat mudah dan tidak mempengaruhi fungsionalitas sistem Tetapi perlu tetap prioritas utama. Setiap pihak tentu  tidak ingin berlayar  keluar dengan produk logo yang salah .
Demikian juga defect bisa keparahan tinggi tetapi prioritas yang rendah Misalkan ada masalah dengan fungsi Email Reservasi Penerbangan. defect ini memiliki keseriusan tinggi karena menyebabkan aplikasi crash, tetapi fungsionalitas dijadwalkan untuk rilis pada siklus berikutnya yang membuatnya menjadi prioritas yang rendah

defect-life-cycle
defect ditugaskan untuk manajer pengembangan proyek yang akan menganalisis defect. Menajer akan memeriksa apakah itu cacat valid. Pertimbangnya bahwa Dalam aplikasi reservasi penerbangan, password hanya berlaku adalah merkuri. Tapi dalam menguji aplikasi untuk beberapa password  yang acak, yang menyebabkan kegagalan logon dan melaporkannya sebagai defe.ct defect tersebut disebabkan karena data uji rusak, melewatkan konfigurasi di lingkungan pengujian, dan hasil yang diharapkan tidak valid dll ditugaskan status ditolak Jika tidak, selanjutnya defect  tersebut akan diperiksa apakah itu di lingkup. Misalkan menemukan masalah dengan fungsi email. defect  tersebut ditunda Selanjutnya, manajer memeriksa apakah defect  serupa telah dibangkitkan eelier. Jika ya defect diberikan status duplikat Jika tidak ada defect maka  ditugaskan untuk pengembang yang mulai memperbaiki kode. Selama tahap ini defect diberi status dalam proses. Setelah kode adalah tetap defect  diberi status tetap Berikutnya tester akan tes ulang kode. Dalam hal ujian melewati defect ditutup. Jika uji kasus gagal lagi defect dibuka kembali dan ditugaskan untuk pengembang
Pertimbangkan situasi di mana pada rilis 1 Penerbangan Reservasi defect ditemukan dalam rangka Fax yang tetap dan diberi sebuah status tertutup Selama rilis upgrade kedua defect  sama lagi kembali muncul.Dalam kasus tersebut, cdefect tertutup akan dibuka kembali. Itu semua untuk Siklus Bug Hidup