Membiarkan bug yang disengaja dalam kode untuk ditemukan penguji


267

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

59
"Tes harus berpikir seperti pengembang" ... menarik. Saya akan berpikir itu jelas bahwa seorang penguji seharusnya tidak berpikir seperti seorang pengembang tetapi seperti seorang pengguna.
Trilarion

12
Apa yang terjadi jika bug yang sengaja diperkenalkan menutupi bug lain yang bisa ditemukan penguji seandainya bug yang disengaja tidak diperkenalkan? Sebagai contoh, misalkan sepotong kode memiliki masalah fencepost dan bahwa tim pengembangan tidak mengetahui bug ini. Seorang programmer memutuskan untuk memasukkan kesalahan fencepost yang disengaja di tempat itu. Sekarang kode memiliki kesalahan fencepost ganda. Misalkan penguji mendeteksi kesalahan, tetapi tidak melihat bahwa itu merupakan kesalahan fencepost ganda. Selamat! Penguji menemukan bug yang diperkenalkan. Kode asli akan dipulihkan untuk mengandung kesalahan fencepost asli. Ups!
David Hammen

20
Saya seorang QE. Saya lebih suka menemukan bug nyata, terima kasih. Saya akan keluar dari perusahaan ini seperti terbakar. Tidak ada yang bisa (dengan sengaja) membuang waktu saya.
ArjunShankar

7
"Kami tidak melakukan ini di perusahaan kami, tetapi salah satu teman saya mengatakan bahwa CTO-nya meminta setiap manajer produk untuk menambahkan fitur tambahan pada awal setiap siklus pengembangan fitur ..."
Marco

3
Saya menduga menambahkan bug yang disengaja menciptakan risiko. Bagaimana jika bug yang disengaja benar-benar memperbaiki sesuatu yang tidak diinginkan? Efek samping positif tidak dilaporkan, kode dihapus dan bug nyata melewati QA. Sesuai dengan sifatnya, "bug disengaja" menit terakhir ini akan dianggap buruk, jika tidak, bug tersebut menghabiskan terlalu banyak waktu pengembang.
Jodrell

Jawaban:


462

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.


17
Pekerjaan QA adalah menemukan bug - bukan; itu untuk memastikan perangkat lunak adalah kualitas produksi. Ini memerlukan klarifikasi. Mengisolasi dan memperbaiki bug adalah salah satu proses penting dalam pengiriman perangkat lunak berkualitas produksi.
Krishnabhadra

21
Sebenarnya, di banyak perusahaan, tugas QA adalah menemukan bug, dan jika ada fitur baru yang ditambahkan ke suatu produk, dan QA saat itu menjalankan test suite yang tidak menunjukkan bug, saya pribadi tidak akan mempercayai test suite itu dan anggap itu tidak lengkap.
Doc Brown

8
Saya setuju, kecuali untuk poin terakhir. Memiliki semacam pendekatan permusuhan antara QA dan pengembangan (dan bisnis) sebagian besar tidak dapat dihindari. Setiap kelompok memiliki keinginan dan keahlian mereka sendiri. Sebagai sebuah perusahaan, ini perlu seimbang untuk bekerja dengan baik. Dalam pengalaman saya, "bermain baik" hanya mengarah pada kelompok yang tidak mendorong agenda mereka, yang mengarah pada stagnasi atau ketidakseimbangan. Perusahaan terbaik yang pernah saya lihat adalah perusahaan tempat pengembangan, QA, dan sisi bisnis mendorong kebutuhan mereka, tetapi bertindak sebagai cek terhadap yang lain, yang mengarah pada kompromi pada keseimbangan terbaik bagi perusahaan.
Telastyn

42
Saya akan menambahkan poin lain: Bug disengaja dapat menyembunyikan yang benar yang akan muncul jika bug disengaja tidak menghentikan proses (dengan melemparkan pengecualian misalnya) sebelumnya.
nkoniishvt

30
Jika saya adalah seorang pria QA dan mengetahui bahwa saya membuang-buang waktu untuk meneliti dan mendokumentasikan serangga omong kosong yang sengaja dibuat, saya akan mencari pekerjaan baru.
Kik

209

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.


26
+1 Sangat setuju dengan semua 4 poin, terutama yang pertama. Pendekatan kompetitif yang dibawa oleh begitu banyak pengembang baru sering mencerminkan 15 tahun sekolah mereka sebelumnya - lingkungan yang sangat kompetitif - tidak seperti tempat kerja di mana kerjasama akan menjadi pendekatan yang lebih baik.
Michael Durrant

1
Lebih suka jawaban ini daripada jawaban teratas.
Pharap

1
"QA tidak hanya ada untuk menemukan bug tetapi juga [...]" - Saya hanya ingin mengatakan bahwa di banyak tempat, istilah pengujian perangkat lunak dan jaminan kualitas digunakan secara bergantian. Ya itu buruk. Di tempat saya dulu bekerja, kami memiliki karyawan yang menggunakan negara bagian - di setiap pertemuan departemen QA - yang kami lakukan di sini bukan jaminan kualitas tetapi kontrol kualitas. (Dia memaksudkan ini sebagai kritik terhadap departemen QA kami.)
Mario

1. Ini sekolah. Setiap hari adalah hari sekolah. Jika Anda bekerja dalam disiplin teknik tetapi Anda tidak ingin belajar setiap hari, Anda harus keluar dari kantor saya. Ini juga sebuah wawancara. Kinerja harus diukur setiap hari untuk memastikan departemen mendapatkan nilai uang. 2. Jika karier saya mengajarkan sesuatu kepada saya, maka QA itu memiliki kapasitas mental anak berusia 14 tahun. Mereka adalah anak-anak dan harus dikelola seperti kawanan domba.
Gusdor

1. Ini bukan sekolah dalam arti bahwa orang dapat berkolaborasi dan tidak bersaing satu sama lain untuk mendapatkan nilai, tidak ada hal seperti menyalin pekerjaan Anda karena tugas harus diselesaikan hanya sekali dan tidak ada malu untuk meminta bantuan dari seorang rekan. Dan 2. Jika QA Anda seburuk itu, masalah Anda ada di SDM, dan mereka yang harus keluar dari kantor.
SparK

100

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.


32
Jika mereka membayar per bug, maka ini
BЈовић

12
"Insentif untuk menemukan bug yang Anda tahu ada di sana" Poin yang sangat baik. Jika suatu organisasi melakukan ini, itu kemungkinan berarti seseorang menghembuskan leher orang-orang QA untuk memastikan mereka menemukan bug yang ditanam, sehingga itu akan menjadi prioritas utama mereka. Bagaimana jika mereka berkumpul dan mencari tahu, katakan, "Hei bug yang ditanam hampir selalu gagal menyimpan satu bidang pada layar edit dengan banyak data" (atau apa pun). Kemudian mereka akan menghabiskan banyak waktu mencari satu jenis bug, dan meningkatkan kemungkinan bahwa mereka akan kehilangan jenis bug lainnya.
Jay

Hal pertama yang terlintas di benak saya adalah Wally akan memberi kode orang lain minivan sore ini
Dan Neely

10
> bug nyata keluar dari pintu. Saya biasa melakukan Pengujian Besar. Anda mulai dengan tesis bahwa kode (non-sepele) selalu mengandung bug. QA adalah pahlawan yang menemukannya sebelum pelanggan menemukannya. Bug selalu ada. Jika Anda memperkenalkan bug artifisial yang Anda buang-buang waktu, Anda bisa menghabiskan waktu untuk menemukan bug asli; waktu untuk pengujian terbatas, Anda mengurangi kualitas dengan menambahkan pekerjaan yang tidak perlu.
RedSonja

58

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.


43
+1 untuk Anda yang tidak pernah benar-benar menguji kode produksi yang Anda maksud dalam dua lintasan ini. Bagaimana Anda dapat berpikir tentang melepaskan tanpa menguji kode produksi adalah di luar saya; jika Anda menguji lagi tanpa bug yang disengaja maka Anda mengulangi upaya Anda dan menyia-nyiakan upaya awal.
adamdc78

51

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",


1
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
yannis

Halo semua. Diskusi agak terlalu panjang untuk dikomentari. Seperti yang dapat Anda lihat dari komentar saya sebelumnya (otomatis), saya telah memindahkan semua komentar ke ruang obrolan khusus . Jika Anda ingin terus mendiskusikan jawabannya, silakan lakukan di ruang obrolan itu, dan jangan di sini. Terima kasih.
yannis

3
Jadi, pendekatan yang dideskripsikan dapat digunakan untuk menguji QA sesekali , bukan sebagai proses permanen.
gerlos

30

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.


28

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.


1
Saya suka ide daya putaran umpan balik!
jxramos

23

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.


Ini akan menjadi satu-satunya cara agar data yang berarti dapat dikumpulkan. Tetapi jumlah waktu dan upaya yang diperlukan untuk menentukan kasus uji yang tepat untuk mendapatkan hasil yang berarti akan mematahkan anggaran dan jadwal. Dan bahkan jika Anda diberi anggaran dan jadwal maka Anda harus mengatasi rintangan memastikan Anda memiliki orang yang memenuhi syarat untuk memahami statistik dan perangkat lunak dengan cukup baik untuk dapat mengidentifikasi subset tes yang tepat. Saya tidak berpikir Anda akan mendapatkan semua itu dalam satu proyek. Jadi dalam kehidupan nyata, cara terbaik yang bisa dilakukan metode ini adalah keliru, jika bukan angka yang menyesatkan.
Dunk

1
Injeksi SQL adalah cara yang baik untuk melakukan ini, karena Anda hanya dapat memilih pernyataan sql secara acak untuk "break"
Ian

1
Masalah besar adalah bahwa bug yang disengaja akan cenderung sangat berbeda dari masalah yang Anda dapatkan secara alami - Anda mungkin hanya melatih QA Anda untuk berpikir seperti programmer. Itu cukup banyak menghancurkan seluruh titik QA - untuk memiliki POV lebih dekat ke pelanggan daripada kode. Sebagian besar dari QA adalah pemeriksaan kewarasan terhadap hal-hal yang devs pikir intuitif (baik karena ketidaktahuan tentang ketidaktahuan pengguna, atau untuk kedekatan dengan kode, waktu yang dihabiskan dengan UI dll). Bug yang disengaja bukan sampel yang didistribusikan dengan baik.
Luaan

20

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.


7
Istri saya melakukan QA selama 8 tahun, dan baru saja pergi ke dev - terutama karena masalah kepercayaan seperti ini. Itu hanya menghina tester.
Bryan Boettcher

19

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.


Poin tentang spec dalam "Dua" adalah analogi yang sangat baik.
Kyralessa

14

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


5
Jika Anda mengabaikan kalimat pertama itu, saya akan memberi Anda +1 karena semua yang lain baik :) Itu hanya ide yang buruk, buruk adalah pernyataan yang meremehkan. Cara termudah untuk membuat QA akuntabel adalah dengan melacak jumlah bug yang membuatnya masuk ke lapangan. Itu saja akan mencapai SEMUANYA metode yang diusulkan mengklaim manfaatnya.
Dunk

@Dunk: Melacak nomor itu tidak akan membuat tim Anda lebih baik secara otomatis, seperti menjaga skor dalam olahraga tidak membuat Anda menjadi atlet terbaik yang bisa Anda capai. Faktanya atlet melakukan latihan , yaitu melakukan tugas-tugas artifisial untuk meningkatkan kinerja mereka dengan cara yang terkendali, yang tidak berbeda dengan apa yang diusulkan di sini. Kecuali Anda memiliki ide bagaimana membuat orang meningkatkan angka itu, nilainya kecil.
back2dos

Saya tidak mengklaim bahwa itu akan meningkatkan apa pun. Saya hanya mengklaim bahwa itu akan menyelesaikan semua metode "masukkan kesalahan palsu" akan menyelesaikan tetapi tanpa semua biaya dan waktu yang terbuang. Apa yang akan dilakukannya adalah memberikan indikasi jika terlalu banyak cacat yang melewati QA. Jika ditentukan sebagai kasus maka proses atau orang-orang perlu dievaluasi kembali. Metode "kesalahan salah" tidak memberikan informasi lebih dari itu, tetapi sebenarnya memberikan informasi yang kurang bermanfaat. Jadi biaya Anda lebih tinggi untuk keuntungan yang lebih sedikit menggunakan metode "kesalahan salah". Seperti yang saya katakan, ide yang mengerikan.
Dunk

@Dunk Kemudian Anda tidak membaca pertanyaan dengan benar. Ini menunjukkan bahwa metode ini meningkatkan moral dan ketelitian. Juga jumlah bug yang berhasil melalui QA tidak dapat diandalkan mengukur efektivitas tim QA. Ini sama-sama dipengaruhi oleh berapa banyak bug yang diperkenalkan pengembang. Jika mereka mulai menggunakan TDD dan ada penurunan tiba-tiba dalam rilis, apa yang dikatakan tentang penguji? Tidak ada.
back2dos

@Dunk Berbeda dengan itu, "kesalahan salah" sebenarnya memberi Anda lebih banyak informasi, dengan asumsi bahwa kesulitan menemukan mereka tidak berfluktuasi tidak menentu (yang dapat diatur). Karena Anda tahu berapa banyak cacat buatan yang ada, Anda dapat mengetahui dengan pasti berapa persen dari mereka yang tertangkap di QA. Jadi informasi tambahan yang Anda dapatkan adalah seberapa efektif QA dalam mendeteksi cacat buatan. Dan angka itu tentu saja lebih banyak berkorelasi dengan efektivitas keseluruhannya daripada yang Anda sarankan.
back2dos

9

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 .


7

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.


1
Saya pikir ada bagian yang baik untuk ini. Lebih baik menemukan bug SEBELUM itu membuatnya menjadi liar, dan saya lebih suka menekan QA internal saya (Itu yang mereka dibayar setelah semua benar?) Daripada menanggapi serangan eksternal. Bug Hunting adalah bagian, dan selama pengujian semacam ini ditangani dengan benar, saya tidak melihat mengapa itu tidak bisa menjadi bagian yang berharga.
WernerCD

1
Salinan "asli" mungkin tidak bebas bug dan juga menurut definisi tidak diuji (karena kode diubah untuk menambahkan bug).
Roger Rowland

1
Menurut pengalaman saya, serangga bukan hewan terisolasi dan mereka tidak duduk sendirian. Perangkat lunak adalah bagian dari suatu sistem dan bug - sengaja atau tidak - mempengaruhi sistem . Kecuali tentu saja kita berbicara tentang perangkat lunak sepele.
Roger Rowland

18
Tidak ada bukti bahwa metode ini akan menemukan 1 bug tambahan bahkan di luar bug yang sengaja disisipkan. Tidak ada bukti bahwa ini akan membuat QA bekerja lebih keras untuk menemukan bug. Mereka mungkin berusaha kurang keras. Juga, karena Anda telah menyia-nyiakan seluruh siklus pengujian prosedur penerimaan tes sementara menguji kode yang sengaja rusak (Tes full blown kami memakan waktu 3 minggu), Anda sekarang harus menguji ulang dengan kode aktual yang akan digunakan karena rusak versi bukan versi yang sama, jadi pengujiannya tidak berguna untuk validasi versi "asli".
Dunk

6
Saya menduga Patton berarti Anda harus memiliki latihan keras dan latihan lapangan selama masa damai. Analoginya adalah memiliki kelas yang ketat di sekolah TI atau pelatihan pasca sarjana. Saya cukup yakin Patton tidak bermaksud bahwa petugas harus diperintahkan untuk menembaki pasukan mereka sendiri dari belakang untuk menjaga pasukan tetap berada di ujung jari mereka!
Jay

7

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.


Sangat setuju dengan hal ini yang menyebabkan masalah rewel yang dilaporkan.
Adam Johns

@ AdamJohns - Anda tidak pernah tahu pasti kecuali Anda mencoba dan mengujinya. Ada cara yang lebih baik, jadi ini hampir menjadi pilihan terakhir bagi saya.
JeffO

7

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.


4
Daripada memiliki pengembang "menyuntikkan" bug dalam kode, waktu mereka akan jauh lebih baik mengidentifikasi bagaimana bug itu bisa didapat dalam sistem untuk memulai dan kemudian memperbaiki kode untuk memastikan bug itu tidak dapat terjadi atau ditangani dengan benar oleh perangkat lunak. Tujuan dari pengembangan proyek bukan untuk menguji sistem QA, itu adalah untuk membangun sistem yang dapat digunakan dan bekerja yang dapat melakukan apa yang diinginkan penggunanya.
Dunk

4

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.


2

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?"


2

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


1

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 .


1

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.


1
Ini adalah argumen melingkar. Anda mengatakan "memasang bug di test build salah karena pengembang tidak seharusnya membuat build dengan kode kesalahan yang diketahui".
Dominic Cronin

@DominicCronin: Tidak ada yang melingkar tentang itu. Apa pun yang dikomit ke repositori harus kualitas terbaik. Ada banyak alasan di sana - menghindari perubahan artifisial dari baris kode adalah satu (wrt "svn menyalahkan" dan fungsi repositori serupa). Bahaya "lupa" untuk mengambil kesalahan lagi. Masalah bahwa penguji pada dasarnya bisa mencari apa yang telah "diunggulkan" dengan melihat log perubahan repositori. Banyak lagi alasan, dengan hampir tidak ada manfaatnya untuk mengimbangi. Tapi saya kehabisan ruang, dan lagi pula idenya adalah untuk memberikan satu , alasan singkat .
DevSolar

@DominicCronin: Atau, dengan kata lain - mungkin ada kasus yang harus dibuat untuk "seeding" bug, tetapi garis harus ditarik dengan baik sebelum melakukan itu ke repo. Dan di sisi lain, walaupun memiliki kode "seeded" untuk pengujian mungkin memiliki satu atau dua hal untuk itu, Anda seharusnya hanya menguji kode yang dilakukan . Kedua ide - masing-masing sudah kontroversial sendiri - sama sekali tidak terhubung dengan cara yang masuk akal.
DevSolar

0

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


2
ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 16 jawaban sebelumnya
nyamuk
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.