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


54

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.


3
Apakah penguji terlibat sebelum membangun? Artinya, apakah mereka terlibat dalam pengembangan persyaratan atau kasus penggunaan atau cerita pengguna, meninjau dokumentasi desain, atau berpartisipasi dalam tinjauan kode? Apakah laporan yang diajukan penguji baik, dan apakah ada pemeriksaan untuk memastikan bahwa laporan itu valid dan lengkap? Jika Anda dapat mengedit pertanyaan Anda untuk menguraikan lebih lanjut tentang peran / tanggung jawab penguji dan bagaimana laporan mereka dikelola, itu akan membantu saya menulis jawaban yang baik.
Thomas Owens

35
Persaingan tidak selalu buruk, tetapi dikombinasikan dengan insentif dapat memiliki efek buruk. Pertanyaan ini mengingatkan saya pada sebuah cerita di The Daily WTF di mana para penguji berkolusi dengan devs untuk membuat bug tambahan yang kemudian dapat ditemukan secara heroik . Menyenangkan membaca. Jangan ulangi kesalahan itu.
Amon

6
Maksud Anda diambil dengan baik, tetapi sebagai tambahan, saya menghargai ketika seseorang mengatakan kepada saya bahwa pekerjaan saya memiliki masalah kegunaan. Itu salah satu hal tersulit untuk diperbaiki dalam perangkat lunak, dan juga yang paling berharga untuk dilakukan dengan benar.
jpmc26

9
Setelah datang dari proyek lebih dari setahun dengan QA yang teliti, saya dapat mengatakan bahwa, sementara cacat tentang memiliki terlalu banyak ruang putih antara elemen atau simbol warna berbeda yang berarti hal yang sama mungkin tampak tidak produktif, mereka pada akhirnya meningkatkan pengalaman pengguna, seringkali meningkatkan produktivitas, mengurangi beban pada dukungan teknis, dan memberikan tampilan dan nuansa yang lebih profesional untuk suatu aplikasi, semua sifat yang diinginkan. Dan, ya, terkadang perangkat lunak akan tertunda karenanya, tetapi harga yang harus dibayar biasanya sepadan.
phyrfox

9
Sejumlah jawaban menunjukkan bahwa tugas penguji adalah menemukan bug; pola pikir inilah yang menghasilkan masalah yang telah Anda identifikasi. Tugas penjaminan kualitas adalah untuk secara akurat menentukan apakah produk memenuhi standar kualitas yang dinyatakan atau tidak . Saya tidak peduli jika penguji menghasilkan laporan bug; Saya peduli apakah seorang penguji menghasilkan analisis yang akurat, berfokus pada pelanggan terhadap kualitas produk. Itulah hal yang harus diberi insentif.
Eric Lippert

Jawaban:


87

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.


5
Hal pertama yang saya pikir mirip - jika mereka ingin mengubahnya menjadi permainan, akan lebih baik jika seorang manajer QA (jika ada) menetapkan poin pada bug yang ditemukan, dengan asumsi orang tersebut dapat dipercaya untuk memiliki kepentingan terbaik dari perusahaan dalam pikiran. Dalam hal ini dia dapat mengendalikan kompetisi dengan lebih baik dan, apakah Anda memandang ini dapat diterima atau tidak, bahkan dapat secara sewenang-wenang menjadikan kompetisi sedikit lebih dekat dengan menetapkan poin yang sedikit lebih tinggi atau lebih rendah demi kompetisi. ( Jika tidak, jika satu orang mendapat jalan maju karena menguji apa yang ditulis pengembang baru itu, semua orang menyerah )
DoubleDouble

2
Meski begitu, saya tidak akan merekomendasikan ide itu karena itu cepat membosankan kecuali anggota tim Anda hampir semuanya sama (yang tidak terjadi). Lebih baik bersaing melawan diri sendiri.
DoubleDouble

1
Terpilih untuk gagasan bahwa mengukur produktivitas QA berdasarkan jumlah bug yang ditemukan setara dengan mengukur produktivitas programmer berdasarkan baris kode yang ditulis (atau poin cerita ditutup). Keduanya konyol tetapi keduanya tetap ada dalam pikiran PHB yang tidak bisa melihat cara yang lebih halus untuk mengukur kinerja.
dodgethesteamroller

Jawaban Anda adalah hal yang sama yang saya pikirkan. Tapi, titik @DoubleDouble tentang tingkat penguji identik adalah titik yang baik untuk berpikir!
Hanya Pikiran Penasaran

2
Sepakat. Meskipun pekerjaan QA saya sebelumnya tidak memiliki kuota yang keras dan cepat, ada beberapa penguji yang merasa paling penting untuk mengganggu setiap nitpick kecil yang dapat mereka temukan - hal-hal seperti "kemeja karakter terlalu panjang, kebanyakan orang melakukannya tidak mengenakan kemeja yang panjang "(ketika panjang kemeja karakter sama sekali tidak relevan dengan permainan) daripada menggali bug nyata seperti" berulang kali menghubungkan / melepaskan kabel jaringan pada host [dalam permainan peer-host] mengakibatkan permainan hangus oleh klien dan menang ditambahkan ke catatan online host ".
Doktor J

17

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.


3
Tugas penguji adalah menemukan sebanyak mungkin bug yang ada, tidak menemukan bug terbanyak. Jika ada dimaksudkan untuk perbedaan besar antara pernyataan tujuan pengujian ini, itu hilang pada saya.
Atsby

6
Karena 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.
Gort the Robot

6
@Abyby jika satu perilaku rusak memanifestasikannya di 10 tempat yang berbeda, maka 1 laporan bug tentang benda rusak sebenarnya jauh lebih baik daripada 8 laporan bug terpisah yang menggambarkan 8 dari 10 gejala yang berbeda.
Peteris

8
@Peteris (dan Steven) Keduanya adalah poin yang menarik, tetapi keduanya tidak dikomunikasikan secara efektif oleh pernyataan yang dikutip Steven .
Atsby

@Atsby Dalam kalimat yang Anda kutip, klausa pertama adalah pernyataan relatif (temukan fraksi bug terbesar), dan klausa kedua adalah absolut (temukan bug terbanyak). Perbedaan antara mengatakan isi ember ini 90% dan isi ember ini dengan 1/2 galon saat ember menampung 1 galon.
dodgethesteamroller

16

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.


+1 tetapi satu-satunya masalah dengan metrik Anda yang lebih baik adalah, ini menciptakan insentif untuk tidak meningkatkan sistem pelaporan bug pengguna ... Idenya benar, tapi mungkin itu harus lebih umum 'bug ditemukan di luar proses pengujian resmi'
user56reinstatemonica8

@ user568458 - Saya berasumsi bahwa organisasi tersebut memiliki tim yang berbeda untuk QA internal dan untuk dukungan yang dihadapi pelanggan, dan bahwa pertanyaan ini hanya membahas QA internal. Jika keduanya adalah tim yang sama, maka Anda memang akan memiliki konflik kepentingan (apakah menggunakan metode saya atau tidak).
bta

6

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.


5

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.


Tidak bisa lebih setuju dengan Moot. Tentu saja orang bisa melakukan sesuatu yang bodoh (mengajukan 100 kesalahan pengetikan, dll) - tetapi "orang bisa melakukan sesuatu yang bodoh" ketika mengikuti skema apa pun.
Fattie

1

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.


Saya harus setuju. Satu hal: jangan membuat ini tentang mendapatkan persetujuan dari manajemen. Untuk membuatnya terasa seperti permainan, penting bagi penguji untuk memahami sendiri aturannya. Jika sistem login adalah masalah prioritas tinggi, beri tahu mereka di muka dan lepaskan. Jika cacat penggunaan kasus lalu lintas tinggi adalah prioritas daripada kasus sudut tidak jelas maka jelaskan dan jelaskan bagaimana skornya. Memiliki prioritas yang jelas akan membuatnya menyenangkan dan membuat orang memancing di lubang pancing yang tepat.
candied_orange

1

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)


-1

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).


1
Saya benar-benar ingin tahu tentang masalah kegunaan. Kami menyebut mereka sebagai "bug dalam spesifikasi".
RubberDuck

1
@RubberDuck Nah jika ini 100% jelas dengan tim, maka ada alasan untuk memberi tahu mereka sambil memberi tahu Anda tidak menyukai apa yang mereka lakukan sama sekali dan mereka tahu mengapa. Jadi peringatkan mereka. Jika ini tidak dibicarakan dengan tim secara khusus, saya tidak berpikir Anda benar-benar bisa marah pada mereka dan hanya memberikan contoh dari satu laporan yang Anda tidak setujui dan beri tahu mereka bahwa Anda tidak menginginkannya seperti itu.
Loko
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.