Apa itu Bug?
Bug adalah konsekuensi / hasil dari kesalahan pengkodean.
Cacat dalam Pengujian Perangkat Lunak
Sebuah Cacat di Software Testing adalah variasi atau penyimpangan dari aplikasi perangkat lunak dari persyaratan pengguna akhir atau kebutuhan bisnis asli. Cacat perangkat lunak adalah kesalahan dalam pengkodean yang menyebabkan hasil yang salah atau tidak diharapkan dari program perangkat lunak yang tidak memenuhi persyaratan sebenarnya. Penguji mungkin menemukan cacat seperti itu saat menjalankan kasus pengujian.
Kedua istilah ini memiliki perbedaan yang sangat tipis, Dalam Industri keduanya adalah kesalahan yang perlu diperbaiki dan digunakan secara bergantian oleh beberapa tim Penguji.
Saat penguji menjalankan kasus pengujian, mereka mungkin menemukan hasil pengujian yang bertentangan dengan hasil yang diharapkan. Variasi dalam hasil pengujian ini disebut sebagai Cacat Perangkat Lunak. Cacat atau variasi ini disebut dengan nama yang berbeda di berbagai organisasi seperti masalah, masalah, bug, atau insiden.
Dalam tutorial ini, Anda akan belajar-
- Laporan Bug
- Proses Manajemen Cacat
- Penemuan
- Kategorisasi
- Resolusi
- Verifikasi
- Penutupan
- Pelaporan
- Metrik Cacat Penting
Laporan Bug dalam Pengujian Perangkat Lunak
Sebuah Bug Report dalam Pengujian Perangkat Lunak adalah dokumen rinci tentang bug yang ditemukan dalam aplikasi perangkat lunak. Laporan bug berisi setiap detail tentang bug seperti deskripsi, tanggal bug ditemukan, nama penguji yang menemukannya, nama pengembang yang memperbaikinya, dll. Laporan bug membantu mengidentifikasi bug serupa di masa mendatang sehingga dapat dihindari.
Saat melaporkan bug ke pengembang, Laporan Bug Anda harus berisi informasi berikut
- Defect_ID - Nomor identifikasi unik untuk kerusakan.
- Defect Description - Penjelasan rinci tentang Cacat termasuk informasi tentang modul di mana Cacat ditemukan.
- Versi - Versi aplikasi tempat ditemukannya kerusakan.
- Langkah - Langkah terperinci beserta tangkapan layar yang dapat digunakan pengembang untuk mereproduksi cacat.
- Date Raised - Tanggal ketika cacat muncul
- Referensi - di mana Anda Memberikan referensi ke dokumen seperti. persyaratan, desain, arsitektur, atau bahkan tangkapan layar dari kesalahan untuk membantu memahami cacat tersebut
- Terdeteksi Oleh - Nama / ID penguji yang mengungkapkan cacat
- Status - Status cacat, lebih lanjut tentang ini nanti
- Diperbaiki oleh - Nama / ID pengembang yang memperbaikinya
- Tanggal Ditutup - Tanggal saat kerusakan ditutup
- Tingkat keparahan yang menjelaskan dampak kerusakan pada aplikasi
- Prioritas terkait dengan urgensi perbaikan cacat. Prioritas Keparahan dapat menjadi Tinggi / Sedang / Rendah berdasarkan urgensi dampak di mana kerusakan harus diperbaiki masing-masing
Klik di sini jika video tidak dapat diakses
Sumber daya
Unduh contoh Kerangka Pelaporan Cacat
Pertimbangkan hal berikut sebagai Manajer Tes
Tim Anda menemukan bug saat menguji proyek Guru99 Banking.
Setelah seminggu, pengembang menanggapi -
Minggu depan penguji merespons
Seperti dalam kasus di atas, jika komunikasi yang rusak dilakukan secara lisan, segera segalanya menjadi sangat rumit. Untuk mengontrol dan mengelola bug secara efektif, Anda memerlukan siklus proses kerusakan.
Apa itu Proses Manajemen Cacat?
Manajemen Cacat adalah proses sistematis untuk mengidentifikasi dan memperbaiki bug. Siklus manajemen cacat berisi tahapan berikut 1) Penemuan Cacat, 2) Kategorisasi Cacat 3) Memperbaiki Cacat oleh pengembang 4) Verifikasi oleh Penguji, 5) Penutupan Cacat 6) Laporan Cacat di akhir proyek
Topik ini akan memandu Anda tentang cara menerapkan proses manajemen kerusakan ke situs web proyek Guru99 Bank. Anda dapat mengikuti langkah-langkah di bawah ini untuk mengelola kerusakan.
Penemuan
Dalam fase penemuan, tim proyek harus menemukan sebanyak mungkin cacat , sebelum pelanggan akhir dapat menemukannya. Cacat dikatakan ditemukan dan berubah ke status diterima ketika diakui dan diterima oleh pengembang
Dalam skenario di atas, penguji menemukan 84 kerusakan di situs web Guru99.
Mari kita lihat skenario berikut; tim pengujian Anda menemukan beberapa masalah di situs web Guru99 Bank. Mereka menganggapnya sebagai cacat dan dilaporkan ke tim pengembangan, tetapi ada konflik -
Dalam kasus seperti itu, sebagai Manajer Tes, apa yang akan Anda lakukan?
A) Setuju Dengan tim penguji bahwa itu cacat
B) Test Manager mengambil peran juri untuk memutuskan apakah masalahnya cacat atau tidak
C) Setuju dengan tim pengembang yang tidak cacat. Benar Salah
Dalam kasus seperti itu, proses resolusi harus diterapkan untuk menyelesaikan konflik, Anda berperan sebagai hakim untuk memutuskan apakah masalah situs web itu cacat atau tidak.
Kategorisasi
Kategorisasi cacat membantu pengembang perangkat lunak untuk memprioritaskan tugas mereka. Artinya, prioritas semacam ini membantu pengembang dalam memperbaiki cacat yang sangat penting terlebih dahulu.
Cacat biasanya dikategorikan oleh Manajer Tes -
Mari lakukan latihan kecil sebagai berikut Seret & Jatuhkan Prioritas Cacat Di Bawah Ini
- Kritis
- Tinggi
- Medium
- Rendah
| 1) Kinerja situs web terlalu lambat |
|
| 2) Fungsi login situs web tidak berfungsi dengan baik |
|
| 3) GUI situs web tidak ditampilkan dengan benar di perangkat Seluler |
|
| 4) Situs web tidak dapat mengingat sesi login pengguna |
|
| 5) Beberapa tautan tidak berfungsi |
|
Berikut jawaban yang direkomendasikan
| Tidak. | Deskripsi | Prioritas | Penjelasan |
|---|---|---|---|
| 1 | Kinerja situs web terlalu lambat | Tinggi | Bug kinerja dapat menyebabkan ketidaknyamanan yang sangat besar bagi pengguna. |
| 2 | Fungsi login situs web tidak berfungsi dengan baik | Kritis | Login adalah salah satu fungsi utama situs web perbankan, jika fitur ini tidak berfungsi, itu adalah bug yang serius |
| 3 | GUI situs web tidak ditampilkan dengan benar di perangkat seluler | Medium | Cacat tersebut mempengaruhi pengguna yang menggunakan Smartphone untuk melihat situs web. |
| 4 | Situs web tidak dapat mengingat sesi login pengguna | Tinggi | Ini adalah masalah serius karena pengguna dapat masuk tetapi tidak dapat melakukan transaksi lebih lanjut |
| 5 | Beberapa tautan tidak berfungsi | Rendah | Ini adalah perbaikan yang mudah untuk orang-orang pengembangan dan pengguna masih dapat mengakses situs tanpa tautan ini |
Resolusi Cacat
Resolusi Cacat dalam pengujian perangkat lunak adalah proses langkah demi langkah untuk memperbaiki cacat. Proses penyelesaian cacat dimulai dengan menetapkan cacat kepada pengembang, kemudian pengembang menjadwalkan cacat untuk diperbaiki sesuai prioritas, kemudian cacat diperbaiki dan akhirnya pengembang mengirimkan laporan resolusi ke manajer pengujian. Proses ini membantu memperbaiki dan melacak kerusakan dengan mudah.
Anda dapat mengikuti langkah-langkah berikut untuk memperbaiki kerusakan tersebut.
- Tugas : Ditugaskan ke pengembang atau teknisi lain untuk diperbaiki, dan mengubah status menjadi Menanggapi .
- Perbaikan jadwal : Pihak pengembang bertanggung jawab dalam fase ini. Mereka akan membuat jadwal untuk memperbaiki kerusakan ini, bergantung pada prioritas kerusakan tersebut.
- Perbaiki cacat : Saat tim pengembangan memperbaiki cacat, Manajer Tes melacak proses memperbaiki cacat dibandingkan dengan jadwal di atas.
- Laporkan resolusi : Dapatkan laporan resolusi dari pengembang saat kerusakan diperbaiki.
Verifikasi
Setelah tim pengembang memperbaiki dan melaporkan cacat tersebut, tim penguji memverifikasi bahwa cacat tersebut benar-benar teratasi.
Misalnya, dalam skenario di atas, ketika tim pengembangan melaporkan bahwa mereka telah memperbaiki 61 cacat, tim Anda akan menguji lagi untuk memverifikasi cacat ini benar-benar diperbaiki atau belum.
Penutupan
Setelah kerusakan diatasi dan diverifikasi, status kerusakan diubah menjadi ditutup . Jika tidak, Anda telah mengirim pemberitahuan ke pengembangan untuk memeriksa cacat itu lagi.
Pelaporan Cacat
Pelaporan Cacat dalam pengujian perangkat lunak adalah proses di mana manajer pengujian mempersiapkan dan mengirim laporan kerusakan ke tim manajemen untuk mendapatkan umpan balik tentang proses manajemen cacat dan status cacat. Kemudian tim manajemen memeriksa laporan kerusakan dan mengirimkan umpan balik atau memberikan dukungan lebih lanjut jika diperlukan. Pelaporan kerusakan membantu untuk berkomunikasi, melacak, dan menjelaskan kerusakan secara detail dengan lebih baik.
Dewan manajemen berhak mengetahui status cacat tersebut. Mereka harus memahami proses manajemen kerusakan untuk mendukung Anda dalam proyek ini. Oleh karena itu, Anda harus melaporkan situasi kerusakan saat ini kepada mereka untuk mendapatkan umpan balik dari mereka.
Metrik Cacat Penting
Kembali skenario di atas. Pengembang dan tim penguji telah meninjau kerusakan yang dilaporkan. Inilah hasil diskusi itu
Bagaimana cara mengukur dan mengevaluasi kualitas pelaksanaan tes?
Ini adalah pertanyaan yang ingin diketahui oleh setiap Test Manager. Ada 2 parameter yang bisa Anda pertimbangkan sebagai berikut
Dalam skenario di atas, Anda dapat menghitung rasio penolakan pembelotan (DRR) adalah 20/84 = 0,238 (23,8%).
Contoh lain, anggap situs web Guru99 Bank memiliki total 64 cacat, tetapi tim penguji Anda hanya mendeteksi 44 cacat yaitu mereka melewatkan 20 cacat. Oleh karena itu, Anda dapat menghitung rasio kebocoran cacat (DLR) adalah 20/64 = 0,312 (31,2%).
Kesimpulannya, kualitas pelaksanaan tes dievaluasi melalui dua parameter berikut
Semakin kecil nilai DRR dan DLR, semakin baik kualitas pelaksanaan pengujian. Berapa kisaran rasio yang dapat diterima ? Kisaran ini dapat ditentukan dan diterima berdasarkan target proyek atau Anda dapat merujuk metrik proyek serupa.
Dalam proyek ini, nilai rasio yang dapat diterima yang direkomendasikan adalah 5 ~ 10%. Artinya kualitas eksekusi uji rendah. Anda harus menemukan tindakan balasan untuk mengurangi rasio-rasio ini seperti
- Tingkatkan keterampilan pengujian anggota.
- Luangkan lebih banyak waktu untuk eksekusi pengujian, terutama untuk meninjau hasil eksekusi pengujian.