Apakah bagus bahwa penguji bersaing untuk melihat siapa yang membuka lebih banyak bug?

Saya seorang pengembang perangkat lunak. Ada tim penguji yang mengikuti dan menjalankan uji kasus yang ditulis oleh analis, tetapi juga melakukan pengujian eksplorasi. Sepertinya para penguji telah bersaing untuk melihat siapa yang membuka lebih banyak bug, dan saya perhatikan bahwa kualitas laporan bug telah menurun. Alih-alih menguji fungsionalitas dan melaporkan bug yang terkait dengan pengoperasian perangkat lunak, para penguji telah mengirimkan bug tentang peningkatan layar, kegunaan, atau bug bodoh.

Apakah ini bagus untuk proyek? Jika tidak, bagaimana saya (sebagai pengembang perangkat lunak), mencoba mengubah pemikiran dan sikap tim penguji?

Masalah lain adalah karena tenggat waktu diperkirakan dan tidak dapat diubah, sehingga saat tenggat waktu semakin dekat, para penguji akan berebut untuk menyelesaikan kasus pengujian mereka, dan ini akan menyebabkan kualitas pengujian menurun. Ini akan menyebabkan bug yang sah berada dalam produk akhir yang diterima oleh klien.

OBS: Kompetisi ini bukan praktik perusahaan! Ini adalah kompetisi antara hanya penguji yang diselenggarakan oleh mereka, dan tanpa hadiah.

Saya tidak berpikir itu baik bahwa mereka membuat kontes karena menemukan bug paling banyak. Meskipun benar bahwa pekerjaan mereka adalah menemukan bug, pekerjaan mereka bukanlah "menemukan bug terbanyak ". Tujuan mereka bukan untuk menemukan yang terbaik, tujuan mereka adalah untuk membantu meningkatkan kualitas perangkat lunak. Memberi penghargaan kepada mereka karena menemukan lebih banyak bug sama dengan memberi hadiah kepada programmer karena menulis paling banyak baris kode, daripada kode kualitas tertinggi.

Mengubahnya menjadi permainan memberi mereka insentif untuk fokus menemukan banyak bug dangkal, daripada menemukan bug yang paling kritis. Seperti yang Anda sebutkan dalam hasil edit, inilah yang terjadi di organisasi Anda.

Orang bisa berpendapat bahwa bug apa pun yang mereka temukan adalah permainan yang adil, dan bahwa semua bug perlu ditemukan. Namun, mengingat tim Anda kemungkinan memiliki sumber daya yang terbatas, apakah Anda lebih suka memiliki fokus penguji beberapa jam atau hari untuk menyelidiki secara mendalam ke dalam sistem Anda mencoba menemukan bug yang sangat besar, atau menghabiskan beberapa jam atau berhari-hari menelusuri aplikasi mencari kesalahan ketik dan kecil kesalahan dalam penyelarasan objek pada halaman?

Jika perusahaan benar-benar ingin membuat game dari itu, berikan pengembang kekuatan untuk menambahkan poin ke bug. "bug bodoh" mendapatkan poin negatif, sulit menemukan bug dengan laporan yang ditulis dengan baik mendapatkan beberapa poin. Ini kemudian memindahkan insentif dari "temukan yang paling" ke "menjadi yang terbaik dalam melakukan pekerjaan Anda". Namun , ini juga tidak dianjurkan, karena seorang programmer dan analis QA dapat bekerja bersama untuk membuat angka-angka mereka secara artifisial.

Intinya: jangan membuat game keluar dari menemukan bug. Temukan cara-cara di organisasi Anda untuk menghargai pekerjaan yang baik dan biarkan begitu saja. Gamifikasi memberi penghargaan kepada orang-orang karena mencapai suatu tujuan. Anda tidak ingin seorang analis QA memiliki tujuan "menemukan bug terbanyak", Anda ingin tujuan mereka "meningkatkan kualitas perangkat lunak". Dua gol itu tidak sama.

Saya akan sedikit tidak setuju dengan jawaban yang lain. "Menemukan bug" untuk tester sama seperti "menulis kode" untuk pengembang. Jumlah mentah tidak ada artinya. Tugas penguji adalah menemukan sebanyak mungkin bug yang ada, tidak menemukan bug terbanyak. Jika tester A menemukan 5 dari 10 bug dalam komponen berkualitas tinggi dan tester B menemukan 58 dari 263 bug dalam komponen berkualitas rendah, maka tester A adalah tester yang lebih baik.

Anda ingin pengembang menulis jumlah kode minimum untuk memecahkan masalah tertentu, dan Anda ingin tester menulis jumlah minimum laporan yang dengan benar menggambarkan perilaku yang rusak. Bersaing untuk menemukan cacat terbanyak adalah seperti berlomba untuk menulis paling banyak baris kode. Terlalu mudah untuk memasukkan game ke dalam sistem agar bermanfaat.

Jika Anda ingin memiliki penguji untuk bersaing, itu harus lebih langsung berdasarkan pada apa yang harus mereka lakukan, yaitu untuk memvalidasi bahwa perangkat lunak berfungsi seperti yang dijelaskan. Jadi mungkin ada orang yang berlomba untuk melihat siapa yang dapat menulis kasus uji yang paling diterima, atau bahkan lebih baik, menulis serangkaian kasus uji yang mencakup sebagian besar kode.

Ukuran produktivitas pengembang yang lebih baik adalah jumlah tugas yang diselesaikan kali kompleksitas tugas. Ukuran produktivitas tester yang lebih baik adalah jumlah kasus uji yang dieksekusi kali kompleksitas kasus uji. Anda ingin memaksimalkan itu, bukan bug yang ditemukan.

Berdasarkan pengalaman pribadi saya, ini bukan hal yang baik. Ini hampir selalu menyebabkan pengembang mengajukan bug yang merupakan duplikat, konyol, atau sepenuhnya tidak valid. Anda biasanya akan melihat banyak dari ini muncul tiba-tiba pada akhir bulan / kuartal saat para penguji bergegas untuk memenuhi kuota. Satu-satunya hal yang lebih buruk dari ini adalah ketika Anda juga menghukum pengembang berdasarkan jumlah bug yang ditemukan dalam kode mereka. Tim pengujian dan pengembangan Anda bekerja melawan satu sama lain pada saat itu, dan yang satu tidak dapat berhasil tanpa membuat yang lain terlihat buruk.

Anda harus tetap fokus pada pengguna di sini. Seorang pengguna tidak tahu berapa banyak bug yang diajukan selama pengujian, yang mereka lihat adalah yang berhasil melewatinya. Pengguna pada akhirnya tidak peduli jika Anda mengajukan 20 laporan bug atau 20.000, asalkan perangkat lunak berfungsi saat mereka mendapatkannya. Metrik yang lebih baik untuk mengevaluasi penguji adalah jumlah bug yang dilaporkan oleh pengguna tetapi yang seharusnya ditangkap oleh penguji.

Ini jauh lebih sulit untuk dilacak. Cukup mudah untuk menjalankan kueri basis data untuk melihat berapa banyak laporan bug yang diajukan oleh orang tertentu, yang saya duga adalah alasan utama mengapa metrik "bug yang diajukan" digunakan oleh begitu banyak orang.

Tidak ada yang salah dengan membuat game dari menemukan bug. Anda telah menemukan cara untuk memotivasi orang. Ini bagus. Ini juga mengungkapkan kegagalan untuk mengomunikasikan prioritas. Mengakhiri kontes akan sia-sia. Anda perlu memperbaiki prioritas.

Beberapa gim nyata memiliki sistem penilaian yang sederhana. Mengapa bug harus diburu?

Daripada skor game hanya dengan jumlah bug yang Anda butuhkan untuk memberikan ukuran kualitas laporan bug. Maka kontes kurang tentang jumlah bug. Ini akan lebih seperti kontes memancing. Semua orang akan mencari bug besar yang akan mendapatkan skor prioritas tinggi. Jadikan kualitas laporan bug bagian dari skor. Mintalah pengembang memberikan umpan balik kepada penguji tentang kualitas laporan bug.

Keseimbangan fine tuning game bukanlah tugas yang mudah jadi bersiaplah untuk meluangkan waktu untuk memperbaiki ini. Itu harus mengomunikasikan tujuan Anda dengan jelas dan itu harus menyenangkan. Ini juga akan menjadi sesuatu yang dapat Anda sesuaikan karena kebutuhan bisnis berubah.

Menemukan bug adalah tugas mereka. Selama mereka tidak membuat hal-hal yang kurang efisien (misalnya, dengan membuka bug untuk ech dari 10 kesalahan ketik, bukan satu untuk menutupi beberapa dari mereka) ini mendorong mereka untuk melakukan persis apa yang seharusnya mereka lakukan, jadi Saya tidak bisa melihat banyak kerugian.

Ini adalah perluasan dari jawaban @ CandiedOrange .

Untuk memulai mengalihkan perhatian ke tujuan yang lebih bermanfaat, pertimbangkan sesuatu yang sangat informal dan tidak resmi. Misalnya, para pengembang dapat membeli beberapa token dan piala kecil.

Setiap hari bahwa setidaknya satu bug signifikan dilaporkan, tinggalkan token "Bug of the Day" di meja penguji. Sekali seminggu, mengadakan upacara dengan prosesi pengembang memberikan token atau piala "Bug of the Week" yang lebih besar dan lebih baik. Buat pengiriman trofi "Bug Bulan Ini" lebih dramatis, mungkin dengan kue. Setiap token atau piala harus disertai dengan kutipan yang mengatakan mengapa pengembang berpikir itu adalah hal yang baik bahwa bug ditemukan dalam pengujian. Salinan kutipan harus diletakkan di suatu tempat di mana penguji semua bisa membacanya.

Harapannya adalah bahwa penguji akan mengalihkan perhatian mereka dari menemukan bug paling banyak untuk mengumpulkan piala dan token terbanyak. Strategi terbaik mereka untuk melakukan itu adalah dengan membaca kutipan dan berpikir tentang pendekatan apa untuk pengujian yang cenderung mengeluarkan bug yang dianggap penting oleh pengembang.

Abaikan saja laporan bug yang tidak penting. Karena itu semua akan sangat tidak resmi dan informal, itu bisa ditutup atau diubah kapan saja.

Apakah ini bagus untuk proyek?

Tidak ada . Anda telah menunjukkan sendiri, bahwa Anda telah mengamati bahwa hal itu menghasilkan laporan berkualitas rendah yang tidak ditargetkan pada fungsionalitas yang disyaratkan, dan bahwa penguji berakhir, untuk memperparah masalah, berebut untuk menyelesaikan pekerjaan yang sebenarnya "seharusnya" "yang akan dilakukan.

Jika tidak, bagaimana saya (sebagai pengembang perangkat lunak), mencoba mengubah pemikiran dan sikap tim penguji?

Sampaikan masalah dengan Manajer Proyek Anda. Mereka harus mempertimbangkan hal semacam ini sebagai bagian dari pekerjaan mereka. Jika PM Anda tidak mau atau tidak mampu menghadapinya, Anda agak macet mengembangkan strategi koping Anda sendiri. (yang akan menjadi pertanyaan yang berbeda)

Saya pikir bagaimana jadinya (atau bagaimana sudah) jika berjalan seperti ini, Anda tidak akan mendapatkan kualitas yang lebih rendah. Meskipun saya pikir itu akan mengurangi rasio kuantitas terhadap kualitas. Tergantung apakah ini hal yang buruk atau tidak. Itu tergantung jika

melaporkan bug tentang peningkatan layar, kegunaan, atau bug bodoh.

adalah sesuatu yang benar-benar tidak Anda inginkan. Jika ini jelas dengan penguji, saya hanya akan memberitahu mereka untuk tidak melakukan hal-hal yang Anda tidak ingin dilaporkan tetapi jelas tentang hal itu. Lakukan ketika salah satu dari laporan itu muncul lagi.

Alasan mereka memiliki kompetisi mungkin untuk bersenang-senang saat bekerja, jadi mereka mungkin tidak berniat melakukan pekerjaan buruk (jika ini dianggap buruk).