Jumat Agung semuanya, teman-teman! Pada akhir Juni, kami meluncurkan grup baru di kursus
Spesialis QA , yang akan menjadi fokus publikasi hari ini.
Ada banyak indikator yang dengannya Anda dapat mengukur efektivitas tim penguji. Salah satunya adalah Rejected Defect Ratio, atau jumlah laporan kesalahan yang ditolak dibagi dengan jumlah total laporan yang diterima. Anda harus berpikir bahwa jika jumlah laporan yang ditolak adalah nol, maka itu bagus, tetapi tidak sesederhana itu. Mari kita lihat jenis kesalahan yang ditolak, lihat bagaimana mereka memengaruhi tingkat kesalahan yang ditolak, dan menghitung rasio yang tepat untuk tim Anda.
Ada tiga kategori kesalahan yang ditolak:
- Kesalahan yang tidak dapat direproduksi;
- Kesalahan salah
- Kesalahan duplikat.
Mari kita mulai dengan kesalahan sendiri.
Kesalahan yang tidak dapat direproduksi
Ada dua jenis kesalahan yang tidak dapat direproduksi. Yang pertama adalah kesalahan yang sangat sulit untuk direproduksi. Ini mungkin kesalahan yang dihasilkan dari interaksi beberapa parameter, beberapa di antaranya Anda bahkan tidak tahu.
Misalkan Anda melakukan beberapa tes berturut-turut, dan salah satu tes mengubah parameter konfigurasi dari nilai default A ke beberapa nilai lain B. Kesalahan terjadi hanya ketika parameter konfigurasi berisi nilai B dan nilai inputnya adalah C. Ketika Mencoba mereproduksi kesalahan, kemungkinan besar Anda ingin memulai dengan kondisi yang diketahui untuk menginisialisasi sistem (atau, mungkin, melakukan instalasi bersih). Tidak ada kesalahan akan terjadi karena parameter konfigurasi sekarang lagi berisi nilai default A.
Varian lain dari jenis kesalahan yang tidak dapat direproduksi ini adalah ketika pengujian benar-benar menemukan cacat, tetapi tidak ada data dalam informasi pemutaran: langkah, nilai input tertentu, atau pemahaman bahwa kesalahan hanya terjadi dengan prosedur tertentu. Akibatnya, upaya untuk mereproduksi kesalahan tidak mengarah ke apa pun.
Namun dalam kedua kasus di atas, memang ada cacat pada produk itu sendiri.
Tipe kedua dari kesalahan yang tidak dapat direproduksi adalah ketika kesalahan tidak dapat diulang karena itu tidak ada. Penguji mungkin telah memperhatikan sesuatu, tetapi disalahtafsirkan, atau sistem yang digunakan untuk pengujian mungkin memiliki beberapa jenis masalah, seperti komponen perangkat keras yang salah, driver yang tidak kompatibel, atau pengaturan akses yang salah. Upaya untuk mereproduksi kesalahan pada kegagalan sistem yang dikonfigurasi dengan benar.
Kedua jenis kesalahan ini biasanya ditandai di sistem pelaporan kesalahan sebagai "ditolak - tidak dapat direproduksi."
Kesalahan salah
Jenis kesalahan ini terjadi jika tester memutuskan bahwa produk harus berperilaku dengan cara tertentu dan melaporkan kesalahan ketika perilaku tidak memenuhi harapannya. Namun, studi yang lebih rinci tentang persyaratan menunjukkan bahwa harapan penguji keliru, dan produk sebenarnya berfungsi dengan benar. Artinya, produk yang diuji bekerja dengan benar, dan penguji, yang tidak cukup akrab dengan persyaratan, membuat kesalahan.
Kesalahan seperti itu biasanya ditandai dalam sistem pelaporan kesalahan sebagai "ditolak - bukan kesalahan" atau "ditolak - oleh arsitektur" (yaitu, perilaku konsisten dengan arsitektur).
Kesalahan duplikat
Kesalahan berulang adalah kesalahan-kesalahan yang telah dilaporkan oleh seseorang, dan kesalahan berikutnya dilaporkan setelahnya. Kesalahan hanya berulang jika "gejala" dari penampilannya sama. Dan jika akar penyebab kesalahan adalah sama, tetapi "gejala" ternyata berbeda, ini bukan pengulangan kesalahan!
Kesalahan ini biasanya ditandai dalam sistem pelaporan kesalahan sebagai "ditolak - duplikat / ulangi."
Bagaimana kesalahan yang ditolak memengaruhi tim
Jelas, kesalahan yang salah adalah semacam pemborosan waktu yang dihabiskan oleh penguji untuk mereproduksi kesalahan dan melaporkannya, waktu bagi mereka yang mengurutkan kesalahan menghabiskan waktu membaca dan memahaminya, dan waktu yang dihabiskan pengembang untuk mencoba mereproduksi kesalahan yang tidak dapat direproduksi atau untuk memperbaiki (dan kerusakan) sesuatu yang tidak perlu diperbaiki ini.
Selain fakta bahwa rasio kesalahan yang ditolak atau RDR adalah ukuran dari ketidakefisienan tim penguji, ia juga berbicara tentang profesionalisme penguji pada umumnya. Kesalahan yang tidak dapat direproduksi karena kurangnya informasi yang diperlukan dalam laporan menunjukkan bahwa penguji tidak teliti dan tidak bekerja cukup keras untuk mereproduksi kesalahan ini menggunakan langkah-langkah yang dijelaskan di atas. Selain itu, untuk kesalahan yang jarang direproduksi, penguji umumnya tidak mencatat frekuensi pemutaran yang rendah dalam laporan.
Munculnya kesalahan yang salah menunjukkan bahwa penguji tidak sepenuhnya memahami persyaratan produk. Kesalahan berulang menunjukkan bahwa penguji tidak melakukan pencarian minimum dalam database kesalahan lokal untuk memeriksa apakah itu terjadi sebelumnya. Atau, itu berarti bahwa spesialis yang melaporkan kesalahan ini bukan yang pertama memasukkan kata kunci yang benar dalam nama untuk memfasilitasi pencarian rekan-rekannya yang lain.
Pada gilirannya, jika ternyata kesalahan yang saya temukan ditolak, saya benci, karena saya dianggap orang awam. Di satu sisi, ini berarti saya akan membela kesalahan yang ditemukan. Ketika laporan saya ditolak, saya melanjutkan sebagai berikut:
- Saya memeriksa lagi apakah kesalahannya mereproduksi di sistem saya dan menambahkan langkah-langkah pemutaran jika saya melewatkan sesuatu;
- Jika kesalahpahaman saya tentang persyaratan disebabkan oleh persyaratan yang ambigu atau dokumentasi yang salah, saya akan bersikeras bahwa kesalahan tersebut ditandai sebagai kesalahan dokumentasi dan ditutup hanya ketika dokumentasi diperbaiki;
- Jika saya percaya bahwa perilaku produk ketika memenuhi persyaratan tidak benar, saya akan berbicara tentang persyaratan dengan arsitek dan pengembang, cobalah meyakinkan mereka bahwa persyaratan tersebut perlu diperbarui (pada akhirnya, saya mewakili pendapat klien!);
- Jika kesalahan ditolak sebagai duplikat, saya akan memastikan bahwa itu tidak ditandai dengan cara yang sama, atau bahwa itu tidak muncul "sesuai dengan skenario yang sama".
Di sisi lain, kemungkinan penolakan kesalahan tertentu membuat saya berhati-hati. Jika saya tidak sepenuhnya yakin bahwa saya menemukan bug, saya akan meluangkan waktu lagi untuk memeriksa sebelum melaporkan. Saya sering bertanya kepada kolega apakah saya menginterpretasikan persyaratan dengan benar, atau saya memeriksa apakah kesalahannya direproduksi pada sistem orang lain.
Pendapat terhadap tidak adanya kesalahan yang ditolak sepenuhnya
Tim pengujian harus memantau dan berusaha untuk mengurangi tingkat RDR. Satu-satunya pertanyaan adalah, RDR apa yang harus dianggap baik?
Sepintas, tampaknya 0% adalah hasil optimal, tapi saya sangat tidak setuju dengan ini. Saya percaya bahwa ketika RDR dijaga pada tingkat yang sehat, ini normal, karena jika mendekati nol, tim pengujian jelas menderita masalah yang tidak kalah serius daripada, katakanlah, RDR yang terlalu tinggi.
Tim pengujian harus melakukan upaya besar untuk mencapai RDR yang sangat rendah. Setiap kesalahan yang ditolak akan dianalisis untuk memahami apa yang salah, dan setiap penguji yang melaporkan kesalahan yang ditolak harus menjelaskan apa yang sebenarnya terjadi dan bagaimana situasi seperti itu dapat dihindari di masa mendatang. Akibatnya, penguji akan melaporkan kesalahan di mana mereka benar-benar yakin.
Jika mereka melihat perilaku yang mereka pikir akan merusak kegunaan produk, mereka akan memilih untuk menerima perilaku seperti itu begitu saja, daripada membenarkan bahwa mereka telah menemukan kesalahan yang, pada kenyataannya, bukan kesalahan berdasarkan persyaratan. Jika mereka memiliki bukti bahwa telah terjadi kesalahan, tetapi tidak ada skenario yang baik untuk mereproduksinya, mereka akan memilih untuk tidak melaporkannya; mereka benar-benar tidak ingin mengecewakan diri mereka sendiri. Jika mereka menemukan bug yang sembrono, mereka mungkin memutuskan untuk tidak melaporkannya sama sekali, karena bug kecil tidak selalu memperbaikinya, jadi mengapa mengambil risiko dan takut kesalahan yang Anda temukan akan ditolak?
Singkatnya, memperjuangkan RDR yang sangat rendah menghasilkan stres dan perilaku tidak sehat dalam tim pengujian, dan juga meningkatkan kemungkinan bahwa beberapa kesalahan tidak diketahui.
Kami membutuhkan penguji yang tidak hanya melaporkan kesalahan nyata, tetapi juga memperingatkan perilaku mencurigakan dalam proyek. Kami percaya bahwa penguji yang sangat mementingkan untuk memastikan bahwa kesalahan tidak hilang, bahkan dengan biaya laporan duplikat, lebih baik daripada penguji yang menghabiskan berjam-jam memeriksa apakah bug telah dilaporkan dalam laporan atau tidak, karena takut mereka buat duplikat. Kami ingin penguji merasa nyaman dengan mempertanyakan kata arsitek sistem atau spesifikasi persyaratan, bahkan jika itu berarti bahwa beberapa kesalahan mereka akan ditandai sebagai ditolak.
Kami membutuhkan penguji yang tidak takut membuat kesalahan dari waktu ke waktu. Ini berarti diperlukan keseimbangan, sehingga beberapa RDR kecil dianggap dapat diterima.
Menemukan koefisien cacat yang ditolak optimal
Aturan praktis saya adalah bahwa RDR harus 15 persen. Nilai ini didasarkan pada pengalaman saya dengan tim penguji, yang, oleh semua akun, adalah tim yang baik dan efektif. Itu adalah RDR kami selama beberapa proyek yang berjalan satu demi satu, sementara tim lain, yang bekerja pada proyek yang sama dan secara paralel dengan kami, meskipun kurang sadar produk dan dianggap kurang efektif, memiliki RDR 30 persen .
Saya tidak berpikir bahwa ada pembenaran untuk makna ini selain perasaan batin saya. Ini jelas tidak ilmiah. Saya tidak akan berdebat dengan tim yang ditujukan pada 10 atau 20 persen, tetapi saya berpikir bahwa memasang dengan 30 persen atau menetapkan tujuan 5 persen sudah menjadi masalah.
Pada akhirnya, ini adalah keputusan yang harus dibuat oleh tim penguji, berdasarkan fitur produk, tingkat keahlian tim, model pengembangan, pengalaman tim pengembangan dan banyak lagi. Saya sangat menyarankan Anda mengawasi RDR dan berpikir apakah Anda perlu melakukan sesuatu dengan itu. Dan jika terlalu tinggi atau rendah, tindakan yang tepat harus diambil.
Secara tradisi, kami menunggu komentar Anda dan mengundang Anda ke
webinar gratis , yang akan diadakan pada 14 Juni. Sampai ketemu lagi!