Membiarkan bug yang disengaja dalam kode untuk ditemukan penguji

Kami tidak melakukan ini di perusahaan kami, tetapi salah satu teman saya mengatakan bahwa manajer proyeknya meminta setiap pengembang untuk menambahkan bug yang disengaja tepat sebelum produk masuk ke QA. Begini Cara kerjanya:

1. Tepat sebelum produk masuk ke QA, tim pengembang menambahkan beberapa bug yang disengaja di tempat acak dalam kode. Mereka mencadangkan dengan benar kode asli yang berfungsi untuk memastikan bahwa bug itu tidak dikirimkan bersama produk akhir.
2. Penguji juga diberitahu tentang ini. Jadi mereka akan menguji keras, karena mereka tahu ada bug yang ada dan tidak menemukan mereka mungkin dianggap sebagai tanda ketidakmampuan.
3. Jika bug (disengaja atau tidak) telah ditemukan, mereka akan dilaporkan untuk diperbaiki oleh tim pengembangan. Tim pengembang kemudian menambahkan bug disengaja lain di bagian kode yang terkait tepat sebelum produk masuk ke QA tingkat kedua. Manajer proyek mengatakan seorang penguji harus berpikir seperti pengembang dan dia harus mengharapkan bug baru di bagian di mana perubahan dilakukan.

Nah, begini caranya. Mereka mengatakan bahwa pendekatan ini memiliki keunggulan sebagai berikut.

1. Penguji akan selalu siap dan mereka akan menguji seperti orang gila. Itu membantu mereka untuk juga menemukan bug tersembunyi (tidak disengaja) sehingga pengembang dapat memperbaikinya.
2. Penguji memakan bug. Tidak menemukan bug akan memengaruhi moral mereka. Jadi memberi mereka yang mudah ditemukan akan membantu moral mereka.

Jika Anda mengabaikan skenario di mana salah satu bug disengaja ini dikirimkan dengan produk akhir, apa kelemahan lain yang harus kita pertimbangkan sebelum berpikir untuk mengadopsi pendekatan ini?

Beberapa klarifikasi:

1. Mereka mencadangkan kode asli dengan benar dalam kontrol sumber.
2. Ketika seorang tester menemukan bug yang disengaja, tim pengembang mengabaikannya. Jika tester menemukan bug yang tidak disengaja (asli), tim pengembangan terlebih dahulu memeriksa apakah itu disebabkan oleh bug yang disengaja. Artinya, tim pengembangan pertama-tama mencoba mereproduksi kode kerja asli dan mencoba memperbaikinya jika mereka bisa.
3. Abaikan saja masalah hubungan antara QA dan tim pengembangan. Saya secara khusus mengajukan pertanyaan ini pada Programmer , bukan pada The Workplace . Pertimbangkan bahwa ada hubungan yang baik antara QA dan tim pengembangan, dan mereka berpesta bersama setelah jam kerja. Manajer proyek adalah seorang lelaki tua yang baik dan selalu siap untuk mendukung kedua tim (Godsend).

Ini kedengarannya benar-benar gila. Ini menghabiskan banyak upaya untuk keuntungan yang sangat dipertanyakan, dan praktik tersebut tampaknya didasarkan pada beberapa premis yang salah:

• QA itu tidak akan bekerja keras kecuali mereka tahu mereka sedang diuji setiap hari (yang tidak baik untuk moral)

• Bahwa tidak ada cukup bug yang diperkenalkan secara tidak sengaja dalam perangkat lunak untuk ditemukan oleh QA

• Pekerjaan QA adalah menemukan bug - bukan; itu untuk memastikan perangkat lunak adalah kualitas produksi

• Bahwa pertarungan akal antara pengembangan dan QA semacam ini dalam beberapa hal sehat untuk perusahaan - tidak; semua karyawan harus bekerja sama melawan pesaing perusahaan, bukan satu sama lain.

Ini adalah ide yang mengerikan dan manajer proyek yang dimaksud adalah brengsek / idiot yang tidak mengerti apa-apa tentang orang dan motivasi. Dan itu buruk untuk bisnis.

Untuk memperluas uraian saya tentang "pekerjaan QA:" QA pasti harus menemukan bug - baik dalam kode dan dalam suite pengujian mereka - sebagai artefak melakukan pekerjaan mereka, tetapi peran tidak boleh didefinisikan sebagai "Anda harus menemukan bug." Seharusnya "Anda harus menjaga suite pengujian tetap mutakhir untuk memperhitungkan fitur baru dan memastikan semua cakupan pengujian yang tinggi. Jika ini tidak menghasilkan bug, maka prosedur pengujian tidak cukup canggih untuk produk.

Nah, berdasarkan apa yang saya pelajari:

1. Itu bukan wawancara sekolah atau pekerjaan;
2. Penguji bukan anak-anak;
3. Itu bukan permainan;
4. Itu membuang-buang uang perusahaan.

QA tidak hanya di sana untuk menemukan bug tetapi juga khawatir tentang seberapa intuitif sistem itu, apa kurva belajar untuk pengguna, kegunaan , dan aksesibilitas secara umum. Misalnya: "Apakah sistem jelek ?", "Apakah warna pengguna buta dan barang-barang berwarna merah dan hijau?" Mereka juga harus mengeluh.

Persyaratan minimal agar sistem dapat lulus QA biasanya dijelaskan dalam cerita pengguna untuk fitur tertentu atau seberapa ajaib PO ingin sistem berada di kepalanya.

tl; dr

Bukan hanya bug, penguji harus tumbuh dari pandangan sempit ini.

Ide buruk.

Dari sudut pandang penguji: "Jadi mereka akan menguji keras, karena mereka tahu ada bug yang ada dan tidak menemukan mereka mungkin dianggap sebagai ketidakmampuan mereka." Pada dasarnya para devs menjebak kode itu. Hanya sedikit orang yang suka melakukan pekerjaan yang pada akhirnya tidak ada gunanya (karena bug sudah diketahui sebelumnya) tetapi masih mempengaruhi bagaimana mereka dipersepsikan. Jika ada hukuman nyata karena tidak menemukan jebakan, lebih dari itu. Dan tahukah Anda, penguji berhasil menemukan bug? Itu terdengar seperti lingkungan konfrontatif yang beracun; seorang QA harus senang jika kode yang mereka periksa berkualitas tinggi. Meskipun jika mereka dibayar oleh bug ... http://thedailywtf.com/articles/The-Defect-Black-Market

Dari sudut pandang dev: QA diberi insentif untuk menemukan bug yang Anda tahu ada di sana. Itu mungkin meningkatkan kemungkinan bug nyata keluar dari pintu; QA menghabiskan setidaknya sebagian dari waktu mereka untuk mencari jenis bug yang mudah ditanam, bukan bug yang benar-benar halus. Plus ada kemungkinan kecil bahwa jebakan dapat berhasil keluar dari pintu.

Saya setuju sepenuhnya dengan jawaban di atas mengapa ini buruk untuk motivasi dan manajemen orang yang buruk. Namun, mungkin ada alasan teknis yang kuat untuk tidak melakukan ini juga:

Tepat sebelum produk masuk ke QA, tim pengembang menambahkan beberapa bug yang disengaja di tempat acak dalam kode. Mereka mencadangkan dengan benar kode asli yang berfungsi untuk memastikan bahwa bug itu tidak dikirimkan bersama produk akhir.

1. Berdasarkan pernyataan pertama, Anda tidak pernah benar - benar menguji kode produksi yang dimaksud dalam dua lintasan ini.

2. Saya akan membayangkan Anda sangat meningkatkan kemungkinan tidak sengaja memasukkan bug 'disengaja' ke dalam kode produksi yang dirilis ketika mencoba untuk terburu-buru melalui perubahan untuk pelanggan. Mungkin menyebabkan beberapa pipi merah di beberapa titik.

3. Saya akan membayangkan bahwa ini hanya melatih penguji Anda untuk berpikir seperti pengembang Anda (yaitu bagaimana Tom akan menambahkan bug di sini) yang mungkin membuat mereka cenderung menemukan bug yang belum dipikirkan Tom.

Sunting

Saya ingin menjadi jelas bahwa jawaban ini hanya berbicara tentang konsep pengujian proses QA Anda, dan saya tidak membela metodologi spesifik yang digambarkan dalam pertanyaan.

Akhiri Edit

Ada alasan yang sah untuk memeriksa apakah pengujian / pemeriksaan Anda benar-benar berfungsi. Biarkan saya memberi Anda contoh dari manufaktur, tetapi prinsipnya sama.

Ini adalah tipikal ketika memberi makan bahan melalui mesin yang mungkin tidak mendorong bahan cukup jauh. Ini disebut "umpan pendek" dan untuk mencegahnya, kami mungkin memasang "sensor umpan pendek" (biasanya sensor tipe sinar yang diblokir oleh material). Sensor ini mendeteksi ujung material saat mencapai panjang umpan penuh. Pada titik tertentu dalam siklus mesin kami memeriksa apakah sensor terhalang, dan menghentikan mesin jika pemeriksaan gagal.

Sekarang Anda harus berpikir tentang bagaimana tes itu sendiri dapat gagal. Sebagai contoh, beberapa kotoran atau puing-puing lainnya dapat menghalangi sensor dan akan selalu melaporkan "OK" dan tidak pernah menghentikan mesin. Juga, sifat dari sensor adalah bahwa penerima menyala ketika sinar menerpa, jadi tergantung pada jenis sensor yang telah Anda instal, secara elektrik Anda mendapatkan input "ON" ketika sensor tidak diblokir . Itu berarti jika kabel terputus atau daya hilang ke sensor itu, atau input gagal, logika program Anda akan membaca "OFF" dan itu berarti "diblokir" atau "OK".

Untuk mengetahui mode kegagalan dari tes ini, kami biasanya menyisipkan pemeriksaan kedua untuk memastikan sensor benar-benar terblokir selama bagian kedua dari siklus. Dengan cara ini kami memeriksa bahwa tes ini sebenarnya masih beroperasi (sebaik mungkin).

Demikian pula ada banyak cara departemen QA bisa gagal. Mungkin pengujian otomatis tidak berjalan dan laporan sedang melihat salinan lama dari data pengujian. Mungkin seseorang tidak melakukan pekerjaannya dengan benar. Menguji departemen QA adalah hal yang wajar untuk dilakukan.

Jelas kelemahannya adalah "bug uji" dapat menembus departemen QA dan menjadi produk jadi. Dalam industri manufaktur kadang-kadang ada kasus di mana bagian buruk yang diketahui, kadang-kadang disebut "Kelinci Merah", dimasukkan ke dalam proses (biasanya oleh seseorang dari QA) dan mereka menonton bagian itu melalui proses dan mengukur berapa lama waktu yang dibutuhkan untuk temukan bagian itu dan hapus. Biasanya bagian ini dicat merah terang (atau oranye) sehingga dapat dengan mudah dilacak. Karena seseorang menonton bagian melalui proses selama tes ini, kemungkinan membuatnya menjadi produk akhir praktis nol. Ada, tentu saja, cerita apokrif tentang seseorang yang melemparkan bagian buruk yang diketahui ke dalam proses untuk "melihat apakah sistem dapat menemukannya",

Jujur, saya menyebut perilaku ini terang-terangan tidak etis dan tidak praktis. PM membutuhkan beberapa pelatihan ulang yang serius, jika tidak pemutusan hubungan kerja.

• Ini menunjukkan kurangnya pemahaman mendasar tentang konsep jaminan kualitas . Penguji seharusnya tidak berpikir seperti pengembang: mereka harus berpikir seperti pengguna akhir. Seluruh alasan untuk memiliki tim QA adalah bahwa pengembang secara inheren terlalu dekat dengan kode; QA seharusnya menjaga jarak yang cukup dari kode sehingga mereka dapat menangkap apa yang para devs lewatkan.
• Itu membuang-buang upaya QA . Dengan asumsi bahwa bug ini tidak sepele-lihat di bawah untuk saat mereka- itu berarti bahwa QA menghabiskan waktu dan sumber daya menyelidiki hal-hal yang sudah diketahui, ketika mereka bisa menghabiskan upaya mencari apa yang tidak diketahui.
• Itu membuang-buang upaya pengembang . Bagi orang-orang QA untuk menangkap bug non-sepele ini, pengembang harus terlebih dahulu menulisnya. Ini membutuhkan upaya lebih lanjut, tidak hanya menghabiskan coding bug, tetapi juga mempertimbangkan persyaratan dan desain perangkat lunak.
• Ini menempatkan produksi pada risiko yang tidak perlu . Hanya masalah waktu sebelum perubahan tidak dapat digabungkan dengan benar.
• Jika tidak melakukan hal di atas, maka itu tidak ada gunanya . Jika semua bug yang diketahui sepele, maka mereka tidak akan menangkap pekerja di bawah standar: mereka hanya akan menangkap orang yang tidak melakukan pekerjaan sama sekali. Ada cara yang lebih baik untuk melakukan itu.
• Ini meracuni lingkungan kerja . Penguji QA Anda adalah profesional. Mereka harus dipercaya untuk menjadi profesional sampai ada alasan sebenarnya untuk mencurigai sebaliknya. Ketika ada adalah alasan untuk mencurigai jika tidak, harus ada investigasi yang tepat bukan permainan pikiran ini. Ada lagi yang bisa membunuh moral.

Serius. Bahkan jika paranoia PM ternyata beralasan dalam kasus khusus ini, ini bukan seseorang yang memiliki penguji pengelola bisnis.

Secara pribadi, saya merasa tidak nyaman dengan pendekatan ini.

Hal utama yang menjadi perhatian saya adalah kepraktisan memasukkan bug yang disengaja . Bagi saya ini sulit dilakukan dengan cara apa pun yang dapat diprediksi.

Setiap perubahan kode (disengaja atau tidak) berisiko memiliki efek samping. Efek samping ini mungkin terungkap selama pengujian tetapi mungkin tidak jelas (bahkan kepada pengembang yang menanam bug) apa penyebab utamanya. Tidak terasa "aman", jika Anda tahu apa yang saya maksud (saya berbicara dari perut saya di sini).

Selain itu, tester akan membuang banyak waktu untuk menguji kode yang sebenarnya tidak akan dirilis. Setelah bug yang disengaja dihapus, tes ulang lengkap harus dilakukan, menurut saya. Itulah inti dari pengujian. Sesuatu berubah, apa saja , dan Anda menguji ulang semuanya . Ok saya tahu itu tidak pernah terjadi dalam praktek, tapi itulah yang dimaksud dengan pengujian regresi.

Jadi, secara keseluruhan, tidak yakin.

Di sisi lain, kami cenderung membiarkan pelanggan memverifikasi pekerjaan tim QA, yang mungkin tidak ideal. Ini adalah umpan balik yang sangat kuat.

Ini adalah ide yang buruk untuk semua alasan yang telah diberikan, tetapi penyemaian bug adalah alat yang berguna untuk tujuan yang berbeda. Anda dapat menggunakannya untuk mendapatkan metrik kasar tentang seberapa efektif proses QA.

Dalam kasus yang paling sederhana, katakanlah Anda menambal 100 bug dan mereka mewakili seluruh bug nyata (saya tahu, tidak mungkin, tapi saya menyederhanakan). Anda tidak memberi tahu QA Anda melakukan ini untuk menghindari memanjakan percobaan. Pada akhir proses QA, katakanlah mereka menemukan 60 dari 100 bug yang diunggah (dan bug nyata lainnya). Sekarang Anda tahu QA menemukan 60% bug.

Anda dapat memperpanjang ini lebih jauh dengan menghitung jumlah bug nyata QA yang ditemukan dan menerapkan rasio bug palsu. Dalam contoh kami, jika QA menemukan 200 bug nyata maka Anda dapat menyimpulkan mereka hanya menemukan 60% dari mereka, jadi 133 tetap ada.

Tentu saja, ini hanya perkiraan luas dengan bar kesalahan besar. Menulis bug yang realistis dan representatif itu sulit. Bug yang Anda tulis cenderung lebih mudah ditemukan oleh QA karena pengembang dilatih untuk tidak menulis bug. Mungkin lebih baik untuk mensimulasikan kelas bug seperti kesalahan off-by-one, kesalahan Unicode, buffer overflows, dan sebagainya.

Ini harus diterapkan pada seluruh proses QA yang akan mencakup pengujian unit pengembang, integrasi berkelanjutan, dan, jika tersedia, tim QA khusus.

Ini adalah metrik , dan tidak boleh dibajak sebagai alat motivasi manajemen.

Ide buruk.

Ini adalah semacam pendekatan logis dan biner yang sering dilakukan oleh pengembang, tetapi ini mendemotivasi untuk QE. Ini hanya menunjukkan kurangnya kepercayaan. QE sering ditempatkan dalam situasi ini tanpa banyak masukan dari mereka, dan diasumsikan bahwa mereka baik-baik saja dengan itu, dan itu bukan tempat mereka untuk menyarankan sebaliknya.

Pemikiran seperti ini menggabungkan QE hanya menjadi penguji manual dan tidak termotivasi untuk memahami kode aktual yang diuji.

Saya seorang QE senior dan ini adalah masalah yang umum di sebagian besar organisasi tempat saya bekerja.

Saya akan mengatakan ide yang buruk.

Satu: Pemrogram akan menghabiskan waktu menempatkan bug yang disengaja dalam kode, dan beberapa upaya untuk menyelamatkan versi yang baik. Sementara penguji mungkin harus menguji semuanya, termasuk fitur dengan bug yang ditanam, ketika mereka menemukan mereka mereka harus kembali dan menjalankan tes itu untuk memverifikasi bahwa ini memang bug (dan bukan bahwa tester menjadi bingung dalam beberapa cara). Minimal, penguji akan menghabiskan waktu menulis bug yang ditanam. Kemudian para programmer harus menghabiskan waktu memperbaiki bug yang mereka tanam. Ini adalah banyak upaya yang bisa dihabiskan untuk mencoba menulis kode yang baik dan menulis bug nyata.

Dua: Ini mengirimkan pesan yang jelas kepada penguji bahwa programmer dan / atau manajemen berpikir mereka tidak melakukan pekerjaan mereka dan harus diperlakukan sebagai anak-anak. Saya tidak dapat membayangkan bahwa ini baik untuk moral. Sebagai seorang programmer, jika saya diberi spesifikasi yang ambigu atau kontradiktif untuk sebuah program dan harus menghabiskan banyak waktu untuk mengklarifikasi, dan kemudian setelah menghabiskan berjam-jam atau berhari-hari bos saya mengatakan kepada saya, "Oh, ya, saya sengaja memasukkan pernyataan yang bertentangan di spesifikasi hanya untuk memastikan Anda benar-benar membacanya ", saya pikir saya akan sangat kesal. Jika itu terjadi secara teratur, itu mungkin cukup untuk membuat saya mencari pekerjaan lain.

Dalam kehidupan nyata, semua kecuali perubahan kode paling sepele AKAN memiliki bug. Saya tidak pernah memiliki masalah dengan penguji yang merasa puas karena kode konsep pertama yang mereka berikan begitu sering 100% sempurna. Saya harus berurusan dengan penguji malas yang tidak melakukan pekerjaan yang memadai, tetapi mereka tidak mendapatkan cara itu karena programmer sangat sempurna. Orang pengujian terbaik yang pernah bekerja dengan saya pernah memberi tahu saya bahwa untuk rilis perangkat lunak baru, ia menetapkan tujuan pribadi untuk menemukan 100 bug. Oke, apakah 100 adalah angka realistis tergantung pada seberapa besar produk itu dan seberapa luas perubahannya, tetapi dalam kasus kami, ia hampir selalu berhasil memenuhi tujuan itu. Terkadang dia harus merentangkan sesuatu, seperti menyebut kata yang salah dieja dalam pesan sebagai "bug", tapi hei, itu memang harus diperbaiki.

Posting skrip: Jika Anda melakukan ini, saya bertaruh bahwa cepat atau lambat programmer akan sengaja menanam bug, penguji tidak menemukan yang khusus, dan programmer lupa untuk mengembalikan kode yang baik. Jadi sekarang bug yang ditanam dengan sengaja dikirimkan ke pelanggan.

Saya pikir ini bukan ide yang buruk . Hanya ada banyak hal yang saya berspekulasi bekerja lebih baik:

1. Buat QA bertanggung jawab atas kualitas dengan cara apa pun yang Anda bisa. Misalnya dengan menjadikan dukungan tanggung jawab mereka juga. Ini akan meningkatkan motivasi mereka untuk memastikan produk yang dikirim memiliki kualitas yang lebih tinggi. Selalu dibutuhkan sedikit usaha untuk menemukan ketidakmampuan (bug, fitur yang jelas hilang, perilaku kontra-intuitif) kemudian mencoba memahami apa yang coba dijelaskan oleh pengguna Anda. Dan menempatkan beberapa tanggung jawab itu bahkan pada pengembang dapat meningkatkan motivasi mereka untuk membantu QA melakukan pekerjaan mereka sebaik mungkin.

2. Memiliki beberapa tim QA, yang dapat bersaing. Anda perlu menemukan metrik yang masuk akal tentu saja. Jelas bukan hanya jumlah masalah. Anjak dalam keparahan cacat atau nilai bisnis (sebagaimana ditentukan oleh pemangku kepentingan) dari peningkatan yang diusulkan harus membantu.

Sulit untuk mengatakan apakah QA "cukup baik". Lebih mudah dan mungkin bahkan lebih baik dalam jangka panjang untuk menemukan cara agar QA menjadi "semakin membaik".

Namun, ada satu masalah yang harus diperhatikan jika Anda memperkenalkan bug yang disengaja: Bagaimana Anda tahu kode "benar" sebenarnya benar pada awalnya? Setelah QA ke-2 Anda menghapus semua bug yang disengaja yang belum ditemukan. Tidak ada cara untuk mengetahui bahwa Anda tidak hanya menggantinya dengan kode yang rusak dengan cara yang berbeda atau bahwa Anda tidak mengaktifkan perilaku rusak yang sebelumnya tidak dapat dijangkau (contoh berlebihan: beberapa dialog tidak terbuka karena bug yang disengaja, tetapi dialognya sendiri rusak - Anda hanya tidak mengetahuinya karena penguji tidak bisa melihatnya).

Seperti yang dikatakan orang lain, pengembang tidak boleh sengaja menambahkan bug dalam perangkat lunak, tetapi itu adalah strategi yang sah untuk rangkaian pengujian Anda untuk menambahkan bug ke dalam perangkat lunak sebagai bagian dari proses pengujian.

Ini disebut pengujian mutasi . Idenya adalah menggunakan perangkat lunak untuk mengotomatisasi pembuatan perubahan kecil dalam kode sumber (disebut mutan). Perubahan dirancang untuk menciptakan perilaku yang berbeda, misalnya, kita bisa berubah

if x < 10:
    print "X is small!"

ke

# we flipped the inequality operator
if x > 10:
    print "X is small!"

dan unit test yang baik harus mendeteksi bahwa fragmen kode mutan tidak lagi berfungsi seperti yang diharapkan dan membunuh mutan . Ketika kode asli lulus tes, dan semua mutan (yang secara fungsional tidak setara) gagal dalam pengujian, maka Anda tahu bahwa kode dan pengujian Anda kuat .

Aku suka gagasan itu. Apakah Jenderal Patton yang mengatakan, "Semakin banyak Anda berkeringat dalam damai, semakin sedikit Anda berdarah dalam perang."

Menempatkan bug yang disengaja "menghabiskan waktu" penguji. Tetapi itu juga membuat mereka bekerja lebih keras, artinya mereka juga akan melakukan pekerjaan yang lebih baik untuk menemukan bug yang tidak disengaja. (Dan Anda memiliki salinan "aslinya" sehingga Anda tidak harus hidup dengan apa yang telah Anda lakukan.)

Menemukan lebih banyak bug yang tidak disengaja kemungkinan akan menghemat lebih banyak kesedihan dalam jangka panjang dibandingkan dengan biaya berurusan dengan bug yang disengaja.

Plus, Anda bisa mendapatkan ide tentang seberapa bagus penguji Anda, bukan manfaat kecil itu sendiri.

Tidak ada dasar untuk hadiah atau hukuman berdasarkan kemampuannya sendiri, tetapi berdasarkan perilaku yang Anda targetkan. Dan terkadang ada konsekuensi yang tidak diinginkan. Adalah tujuan untuk menjaga tim QA dari mengendur atau membuat beberapa manajer merasa seperti dia benar-benar menyumbangkan sesuatu tanpa menyadari bahwa dia hanya menghalangi.

Hasil Positif - Tim QA bekerja lebih keras untuk menemukan bug. Siapa tahu, mungkin mereka melihat ini sebagai tantangan. Ini adalah pertandingan persahabatan. Atau mereka hanya melakukannya karena sedang diawasi (Efek Hawthorne?).

Hasil Negatif - Mereka mungkin tidak bekerja lebih keras dan tetap menemukan bug. QA melihat ini sebagai picik dan permusuhan. Jadi sekarang, mereka masuk ke drive mencari bug dan mengembalikan segala macam masalah kecil yang rewel. Font itu tidak ditampilkan dengan benar ketika saya mengambil screenshot dan mengubahnya menjadi pdf dan melihatnya 500%.

Tanpa Dampak - terdengar bagi saya seperti ini tidak ada bedanya, jadi mengapa repot-repot? Anda berisiko membuang-buang waktu dan membuat orang jengkel.

Kita semua bisa sepakat bahwa ini tidak akan berhasil 90% dari waktu. Itu tidak banyak manfaatnya bagi 10% lainnya. Uji berbagai hal untuk diri Anda sendiri. Apakah pelanggan lebih puas dengan rilis yang memiliki bug kode yang disengaja? Apakah itu memengaruhi moral dan produktivitas pekerja di bidang lain? Tingkatkan turnover? Anda memberi tahu kami.

Berasal dari dunia tempat pengembang diharapkan untuk menulis dan menjalankan tes sendiri, silo "pengujian" "QA" yang Anda maksudkan ini menakutkan dan membingungkan saya, jadi saya akan mencoba menjawab dari perspektif ini. Sebagai tambahan, insinyur QA yang berkualifikasi, dari sudut pandang saya, (seperti yang dijelaskan dengan baik dalam jawaban @ SparK), harus fokus pada masalah yang lebih besar untuk memastikan bahwa perangkat lunak sepenuhnya memuaskan cerita pengguna dan memiliki "kualitas" secara keseluruhan (sehubungan dengan domain untuk perangkat lunak ini dimaksudkan), alih-alih mencari bug.

Yang menarik saya di sini adalah penyebutan @ JamesMcleod tentang "injeksi cacat" dalam komentar untuk pertanyaan. Saya benar-benar berpikir bahwa membuat para pengembang berpikir bagaimana mereka dapat menyuntikkan bug ke dalam sistem adalah ide bagus untuk menargetkan konsep pertahanan secara mendalam. Tidak ada satu bug pun yang cukup untuk menjatuhkan seluruh sistem dengan cara yang tidak terkendali (tanpa penebangan yang jelas dapat ditindaklanjuti), menyebabkan korupsi data, atau dengan sendirinya mengekspos kerentanan keamanan.

Memiliki pengembang dari masing-masing komponen membuat cacat yang disengaja, menangani mereka dari komponen lain dan secara keseluruhan memasuki pola pikir yang lebih bermusuhan tentang perangkat lunak mereka mungkin dapat melakukan banyak hal untuk meningkatkan ketahanan perangkat lunak. Bahkan manfaat langsungnya bisa jadi signifikan - saya mengharuskan selama setiap injeksi jenis cacat baru (yang sampai sekarang belum teruji), pengembang akan segera menutupinya dengan tes baru, yang akan ditetapkan dengan bendera yang akan memungkinkan bug untuk hidup di basis kode tidak terganggu untuk sementara waktu, dan kemudian dihidupkan sebelum pengiriman (dan cacat dihapus), untuk berubah menjadi tes reguler yang akan membuat test suite lebih komprehensif.

Opsi terkait adalah penggunaan flag fitur untuk mematikan fitur pada komponen tertentu untuk memeriksa bagaimana komponen lain mengatasinya. Saya juga sangat merekomendasikan membaca buku / artikel gratis "Belajar dari Responden Pertama: Ketika Sistem Anda Harus Bekerja" yang menggambarkan pengujian ekstensif seperti infrastruktur perangkat lunak yang akan digunakan oleh tim Obama untuk pemilihan 2012.

Seperti yang orang lain katakan, bukan tugas QA untuk menemukan bug saja. Saya akan melangkah lebih jauh dan mengatakan itu bukan pekerjaan mereka sama sekali, secara teknis. Pengembang harus bertanggung jawab untuk menjaga kode mereka sendiri bebas bug. Suite uji harus dijalankan sebelum kode baru bahkan pernah dilakukan, dan jika test suite gagal, maka seharusnya tidak pernah membuatnya ke QA. Mengenalkan bug dengan sengaja berarti Anda pasti tidak dapat lulus suite tes Anda, jadi mengapa kode Anda menuju QA?

Tugas QA adalah memvalidasi aplikasi terhadap cerita pengguna yang diterapkannya. Mereka harus menguji alur, UI, dll. Dan memastikan bahwa pengguna dapat melakukan semua yang harus dapat dilakukan pengguna, dengan cara yang paling mudah digunakan dan dapat diakses. Saat melakukan ini, tentu saja, mereka mungkin menemukan bug, tetapi itu adalah efek samping dari apa yang mereka lakukan, bukan apa yang mereka lakukan. Ingat QA berarti Jaminan Kualitas, bukan Jaminan Bebas Bug.

Ini tidak semanis kedengarannya. Ini lebih tergantung pada motivasi Anda. Jika Anda mencari tongkat untuk mengalahkan tim uji Anda, yah itu akan gila. Di sisi lain, salah satu hal paling sulit dalam pengembangan perangkat lunak adalah mengetahui seberapa efektif pendekatan pengujian Anda.

Jadi, jika Anda menyusunnya dengan benar, Anda bisa menggunakan teknik ini untuk memperkirakan berapa banyak bug tidak ditemukan yang tersisa dalam produk yang akan Anda kirim. Jadi bayangkan bahwa Anda telah secara sengaja menambakan 100 bug dalam bangunan pengujian Anda, dan penguji menemukan 50 bug. Kemudian Anda dapat menyimpulkan bahwa ada kemungkinan tertentu bahwa jika mereka juga menemukan 50 bug yang tidak dibutuhkan, mungkin ada 50 yang tersisa untuk ditemukan.

Tentu saja, ini penuh dengan banyak masalah. Anda dapat memutuskan apakah akan mengirim berdasarkan statistik ini, tetapi dalam kehidupan nyata, Anda mungkin menemukan satu masalah yang sangat buruk, atau ribuan gangguan kecil.

Tetap saja - pengetahuan adalah kekuatan, dan tanpa teknik ini, Anda bahkan kurang tahu tentang kualitas basis kode Anda. Jika Anda dapat menerapkannya dengan hormat dan untuk alasan yang tepat, saya akan mengatakan "Mengapa tidak?"

Satu hal yang belum disebutkan orang lain: pengujian mutasi .

Di sinilah alat otomatis mengambil kode sumber Anda dan dengan sengaja memasukkan bug ke dalamnya. (Misalnya, hapus pernyataan yang dipilih secara acak, ubah AND menjadi OR, atau apa pun.) Itu kemudian menjalankan suite tes lengkap Anda, dan memeriksa apakah tes lulus.

Jika semua tes lulus, maka ada dua kemungkinan:

• Hal yang diubah tidak melakukan apa-apa. Dengan kata lain, Anda memiliki kode mati.
• Perubahan tersebut memperkenalkan bug yang tidak ditangkap oleh suite pengujian Anda. Anda perlu lebih banyak tes.

Perhatikan bahwa, tidak seperti proposal Anda, semua yang saya jelaskan di atas adalah otomatis . Anda tidak membuang waktu pengembang memasukkan bug tanpa tujuan dengan tangan. Dan Anda tidak membuang waktu penguji untuk menemukan bug yang dikenal. Satu-satunya hal yang Anda habiskan adalah waktu alat berat, yang jauh lebih murah. (Mesin tidak bosan melakukan tes yang sama 20.000 kali. Manusia berhenti merawat setelah beberapa saat!)

Saya akan menyarankan bahwa pengujian mutasi otomatis adalah pendekatan yang jauh, jauh lebih baik daripada skenario manual yang Anda bicarakan.

Perhatikan bahwa jika Anda meminta pengembang untuk memasukkan bug secara manual, jenis bug yang Anda dapatkan mungkin tidak mewakili jenis kesalahan tidak disengaja yang mungkin dilakukan manusia. (Misalnya, jika Anda belum menyadari ada kemungkinan kondisi balapan, Anda juga tidak mungkin memasukkan yang disengaja.) Apakah alat otomatis yang dikelola untuk menjadi lebih objektif masih harus dilihat, tentu saja ...

Meskipun itu adalah ide yang buruk secara umum (jawaban yang lain menjelaskan dengan sempurna alasannya), ada beberapa situasi khusus di mana secara sengaja menyuntikkan bug ke dalam kode produksi secara terkendali dan sementara dapat masuk akal.

Ketika Anda membuat ulang kode uji - dan Anda harus, kode uji layak mendapatkan perhatian yang sama terhadap detail seperti kode produksi - Anda mungkin ingin tahu apakah kode uji masih menemukan bug yang seharusnya ditemukan.

Anda kemudian dapat dengan sengaja memecahkan kode produksi untuk memverifikasi jika tes masih berfungsi.

Ada beberapa level yang memungkinkan:

• Pengembang yang baru saja melakukan refactored beberapa pengujian unit mungkin melanggar kode produksi untuk memverifikasi bahwa pengujian unit masih menemukan apa yang seharusnya ditemukan.
• Penguji yang baru saja melakukan refactored beberapa tes penerimaan mungkin melanggar kode produksi untuk memverifikasi bahwa tes penerimaan masih memverifikasi apa yang seharusnya diverifikasi.
• Jika antarmuka stabil dan cukup kuat (yaitu berbasis protokol), perusahaan mungkin ingin menyimpan serangkaian versi produk yang salah dan menjalankan tes terhadap mereka untuk menguji regresi tes.

Apakah hal-hal ini masuk akal tergantung. Jika saya seorang pengembang dan hanya butuh satu menit untuk menyuntikkan bug, uji coba unit, hapus bug - lalu mengapa tidak. Tetapi saya harus memiliki editor saya, siklus saya dan sistem kontrol versi saya di bawah kontrol yang baik sehingga saya tidak akan sengaja melakukan / mengirim / check-in / mendorong bug. Hal yang sama berlaku untuk tester dan tes penerimaan.

Apakah masuk akal bagi suatu organisasi untuk menyimpan suite versi produk yang salah yang diketahui dan uji regresi tergantung pada tes tersebut. Untuk toko online saya tidak mau. Untuk embedded otomotif, tertanam dirgantara, kartu perbankan atau kartu TV berbayar saya akan.

Berapa banyak upaya ini sangat tergantung pada seberapa terpisah tes dari kode produksi. Semakin terpisah tes dari kode produksi, semakin sedikit upaya untuk melakukan ini, semakin kohesif tes dengan kode produksi, semakin banyak upaya.

Alasannya sederhana ini: Ketika pengujian Anda dan kode produksi Anda bersifat kohesif, mengubah kode produksi sering membutuhkan pengujian, dan itu akan memutus ketergantungan antara tes dan sampel produksi yang salah. Anda kemudian juga harus mempertahankan sampel produksi yang salah. Dalam kasus yang jarang terjadi, bahkan yang sepadan dengan usaha, dan mengejek serta penggunaan cerdas dari sistem kontrol versi dapat secara signifikan mengurangi upaya, tetapi itu membutuhkan jauh di atas pengembang yang terampil.

Konsep kesalahan menyuntikkan sengaja dalam kode produksi disebut sabotase , kesalahan disuntikkan disebut saboteur .

Seorang penguji yang tidak mengambil kode yang akan diuji langsung dari repositori melakukan kesalahan. (1)

Pengembang yang memeriksa kode yang diketahui salah ke dalam repositori melakukan kesalahan. (2)

Jadi pada tahap ini, sudah tidak ada cara bagi skema ini untuk bekerja tanpa satu atau kedua belah pihak melanggar premis yang sangat mendasar tentang bagaimana pengembangan dan pengujian harus dilakukan.

(1) Karena Anda perlu mendokumentasikan versi yang Anda uji. Versi yang ditandai oleh hash Git atau nomor revisi SVN adalah sesuatu yang dapat Anda uji, "kode yang diberikan Joe kepada saya" tidak.

(2) Karena Anda tidak melakukannya, di luar penguji yang mengharapkan kegagalan.

Ini merupakan upaya dengan alasan "elevator pitch" yang sesingkat mungkin yang harus segera dipahami oleh para dev, penguji, dan manajemen.

Saya merekomendasikan agar tidak sengaja menyuntikkan bug ke SETIAP bangunan yang Anda kirim ke QA.

Anda dapat, dari waktu ke waktu, katakanlah setahun sekali, melakukan "audit QA" terselubung. Ambil basis kode "teruji dan berfungsi", dan sebanyak mungkin fitur baru dari daftar Todo Anda. Terapkan mereka "sedikit lebih sembrono" daripada yang biasanya Anda lakukan. Pikirkan kasus tepi, tulis, tetapi jangan perbaiki kode Anda untuk memperhitungkannya. Kirimkan ke QA.

Jika mereka menemukan lebih banyak bug tepi yang tidak berfungsi daripada yang Anda tulis, tentu bukan QA Anda yang memerlukan pengawasan ... ;-)