Mengapa membiarkan / tidak membiarkan pengembang menguji pekerjaan mereka sendiri

Saya ingin mengumpulkan beberapa argumen mengapa membiarkan pengembang menguji pekerjaannya sendiri sebagai langkah terakhir sebelum produk masuk ke produksi adalah ide yang buruk, karena sayangnya, tempat kerja saya kadang-kadang melakukan hal ini (terakhir kali ini muncul , argumen itu bermuara pada kebanyakan orang yang terlalu sibuk dengan hal-hal lain dan tidak punya waktu untuk membuat orang lain terbiasa dengan bagian dari program tersebut - ini adalah perangkat lunak yang sangat khusus).

Ada rencana pengujian dalam kasus ini (meskipun tidak selalu), tetapi saya sangat mendukung membuat seseorang yang tidak melakukan perubahan yang diuji sebenarnya melakukan pengujian akhir. Jadi saya bertanya apakah Anda bisa memberi saya daftar argumen yang baik dan solid yang bisa saya kemukakan saat ini dibahas. Atau untuk memberikan argumen balasan, jika Anda berpikir ini baik-baik saja terutama ketika ada kasus uji formal untuk menguji.

Seperti yang orang lain (dan Anda sendiri) catat, pengembang harus menguji kode mereka sendiri. Namun, setelah itu, produk nontrivial apa pun juga harus diuji oleh orang independen (departemen QA dan / atau klien sendiri).

Pengembang biasanya bekerja dengan pola pikir pengembang tentang "bagaimana membuat ini bekerja?" . Seorang penguji yang baik sedang memikirkan "bagaimana cara memecahkan ini?" - Pola pikir yang sangat berbeda. Pengujian unit dan TDD memang mengajarkan pengembang untuk mengubah topi sampai batas tertentu, tetapi Anda tidak harus bergantung padanya. Selain itu, seperti yang telah dicatat oleh orang lain, selalu ada kemungkinan kesalahpahaman persyaratan. Oleh karena itu tes penerimaan akhir harus dilakukan oleh seseorang yang sedekat mungkin dengan klien .

Pengembang tahu bagaimana kode mereka bekerja dan akan terbiasa menguji kode mereka sesuai dengan pengetahuan ini.

Pengembang akan merasa sulit untuk menghapus diri mereka dari pola pikir 'cara kerjanya' sebagai lawan dari 'bagaimana seharusnya bekerja'.

Karena itu, lebih baik untuk mendapatkan seseorang dengan tingkat objektivitas yang tinggi untuk menguji program yaitu QA atau Test Engineers

Testers Test to break, Simple. Jenis bias ini diperlukan untuk benar-benar mengetahui penghenti acara.

Pengembang HARUS menguji pekerjaan mereka. Itu adalah tanggung jawab yang tersirat.

Saya berasumsi Anda tidak memiliki tim yang didedikasikan untuk melakukan tes berdasarkan pernyataan Anda. Namun, memiliki tim yang didedikasikan untuk pengujian akan sangat membantu karena pengembang cenderung menguji kode mereka dengan cara mereka mengkodekannya. Itu tidak berarti bahwa begitu Anda memiliki tim penjaminan kualitas, Anda sudah dapat melakukan pengujian sebagai tanggung jawab pengembang.

Pengembang biasanya menggunakan jaring dengan lubang besar untuk menangkap serangga. Akibatnya, bug yang lebih kecil lolos.

Karena pengembang tidak pandai mencoba memecahkan kode mereka sendiri. Pikiran mereka hanya mengikuti jalur entri dan interaksi data yang benar dengan aplikasi. Banyak bug adalah hasil dari berinteraksi dengan sistem seperti orang normal . Pengembang bukan pengguna normal. Mereka adalah pengguna profesional.

Ada beberapa alasan bagus untuk memiliki tim pengujian khusus. Pertama, seperti yang disebutkan di atas, pengembang sangat pandai menguji bahwa kode mereka berfungsi, tetapi tidak merusaknya.

Juga, seperti yang Anda katakan, pengembang tahu apa yang mereka tulis, tetapi tim pengujian tahu apa yang seharusnya ditulis. Kadang-kadang, kedua konsep ini tidak cocok. Salah satu tugas dari tim pengujian adalah memastikan bahwa perangkat lunak memenuhi persyaratan. Dalam banyak kasus, pengembang hanya mengetahui beberapa bagian dari sistem dengan sangat baik tetapi tim QA mengetahui semuanya.

Yang mengarah ke alasan berikutnya, tim pengujian melakukan pengujian integrasi penuh. Sepotong kode yang baru saja Anda tulis mungkin berfungsi dengan baik sendiri, tetapi dapat merusak fungsi lain yang tidak Anda ketahui.

Setelah bekerja dengan tim QA dan tanpa, saya dapat memberi tahu Anda bahwa saya 100% menghargai pekerjaan yang mereka lakukan dan akan mengatakan bahwa mereka adalah bagian yang berharga dari tim perangkat lunak. Ketika Anda memiliki tim QA, itu membuat melepaskan kode Anda jauh lebih mudah, b / c Anda tahu itu telah diuji secara menyeluruh dan itu berarti Anda akan mendapatkan lebih sedikit panggilan 3am.

Pengembang harus menguji unit kode mereka sendiri.

Penguji independen tidak hanya menguji untuk menerobos, mereka menguji asumsi yang tidak dinyatakan dan tidak terdefinisi yang dibuat pengembang saat mengode.

Saya berharap pengembang untuk melakukan beberapa pengujian awal sebelum mereka melakukan perubahan apa pun dan untuk meyakinkan diri sendiri bahwa kode itu berfungsi. Saya kemudian mengharapkan pengembang untuk memasukkan ke dalam kasus uji pengetahuan khusus 'kotak putih' yang mereka miliki. Misalnya merinci area lain dari kode yang mungkin terpengaruh.

Keberatan utama untuk pengembang menguji kode mereka sendiri adalah bahwa Anda hanya menguji satu sudut pandang. Pengembang telah membaca spesifikasi dan menafsirkannya. Semoga spesifikasinya jelas, lengkap dan tidak ambigu, tetapi ini tidak selalu terjadi. Pengembang mungkin salah memahami bagian dari spesifikasi. Jika mereka menguji kode mereka sendiri maka ini tidak akan ditangkap karena mereka akan menemukan fungsi beroperasi seperti yang mereka harapkan.

Orang yang berbeda juga akan cenderung menggunakan produk dengan cara yang berbeda dan mengambil rute yang berbeda melalui kode sebagai hasilnya. Pengembang akan memastikan bahwa kode tersebut berfungsi untuk mereka, tetapi mungkin tidak mempertimbangkan kasus tepi yang mungkin ditemukan oleh penguji lain.

Pengembang harus menguji pekerjaan mereka sendiri. Membiarkan pengembang mendorong pekerjaan yang belum diuji ke tim QA, atau kolega pengembangnya adalah Ide yang Sangat Buruk. Itu membuang-buang waktu pengembang dan penguji sama, dan merusak hubungan.

Namun, itu tidak selalu cukup. Pengembang cenderung mengikuti jalan yang bahagia melalui sistem, atau menjadi buta terhadap beberapa keistimewaan yang telah mereka alami berulang kali selama pengembangan.

Poin lain adalah bahwa mungkin ada sejumlah lapisan komunikasi antara spesifikasi dan penyebaran. Ini dapat menyebabkan efek Whispers Tiongkok pada penyebaran akhir. Yang terbaik adalah siapa pun yang mendefinisikan persyaratan atau laporan bug menguji bahwa itu berfungsi seperti yang mereka inginkan.

Sebagai pengembang Anda bertanggung jawab atas kode Anda sendiri, Anda harus mengujinya. Does the feature work as expected?Jika jawabannya ya, Anda sudah selesai.

Mengapa Anda tidak melakukan uji kasus?

1. Anda subjektif , karena bug yang ditemukan ditulis oleh Anda (atau kolega Anda).
2. Anda terlalu mahal bagi perusahaan untuk menjalankan tes kasus. (Saya harap).

Biasanya, pengembang tidak akan, dalam banyak kasus, menjadi orang yang menggunakan kode kecuali dalam kasus khusus tertentu. Jadi langkah pengujian terakhir sebelum promosi ke sistem produksi harus pengujian penerimaan pengguna, UAT. Mereka umumnya [seharusnya] lebih terbiasa dengan apa yang mereka harapkan dilakukan paket. Dan umumnya lebih mampu memecahkan hal-hal dengan arus masuk yang tidak biasa bagi seseorang yang tidak menggunakannya setiap hari.

Apakah rencana proyek Anda tidak diperuntukkan bagi pengujian pengguna? Jika Anda mendapatkan pengguna untuk mengujinya, Anda mungkin menangkap bug lebih awal dari pasca-implementasi yang di dunia saya bukanlah hal yang buruk.

Pengembang tidak boleh menguji kode mereka sendiri karena itu sama dengan menilai seni anak Anda sendiri. Bagaimanapun juga, itu akan terlihat cantik untuk Anda, dan Anda benar-benar membutuhkan profesional untuk menunjukkan kekurangannya. Pengujian unit di sisi lain mirip dengan memastikan anak Anda tidak mencoba melukis dengan timah.

Jika Anda BENAR-BENAR tidak ingin mempekerjakan QA, mintalah pengembang untuk menulis kode uji untuk pengembang lain. Itu adalah langkah pertama yang baik - segera Anda akan melihat pengembang meminta sumber daya QA karena sebagian besar waktu mereka dihabiskan untuk menguji kode orang lain untuk masalah, selain CR.

Bukan hanya pengembang yang melindungi kode mereka, jika mereka tidak menyadari kasus tertentu, atau salah mengartikan spesifikasi dalam cara mereka mengembangkan sesuatu, maka mereka akan kehilangan kasus-kasus ketika menguji kode mereka.

Teknik dan keterampilan untuk pengujian keduanya sangat berbeda.

Sebagian besar pengujian oleh tim uji fungsional (bahwa produk berfungsi sesuai spesifikasi) dan kotak hitam (tim uji tidak akan melihat bagian dalam aplikasi). Penguji fungsional tidak perlu khawatir dengan cara kerja sesuatu, mereka hanya perlu fokus pada apakah mereka melakukannya.

Dalam pengalaman saya, setidaknya di organisasi kecil saya, pengguna akhir perlu menguji. Hampir setiap proyek yang kami dapatkan, mereka gagal memberikan semua informasi yang dibutuhkan, dan selalu meninggalkan detail tertentu. Pengembang selalu berada pada posisi yang kurang menguntungkan karena dia tidak tahu bagaimana melakukan pekerjaan pengguna, jadi sementara dia tahu perangkat lunak itu bekerja sesuai dengan info yang diberikan, dia tidak tahu apakah itu akan membantu pengguna akhir lakukan pekerjaan mereka.

Pengembang salah membaca dan salah menafsirkan persyaratan dan mereka yang bertanggung jawab atas persyaratan sering gagal menentukan hal-hal utama. Jika tidak ada orang selain tes pengembang, maka tidak ada yang akan menemukan terputusnya ini sebelum ditayangkan. Saat pengembang menguji, mereka tahu terlalu banyak tentang bagaimana seharusnya bekerja dan tidak mencoba hal-hal bodoh yang mungkin dicoba pengguna. Pengembang juga menulis tes mereka berdasarkan interpretasi mereka sendiri dari persyaratan yang terlalu sering tidak apa yang sebenarnya dimaksudkan. Jadi tes lulus tetapi persyaratan tidak terpenuhi. Ketika Anda memiliki orang yang berbeda pengujian, orang itu mungkin memiliki ide yang berbeda tentang persyaratan dan Anda sering menemukan tempat-tempat di mana persyaratan tersebut diungkapkan dengan buruk oleh betapa berbedanya dua orang berbeda menafsirkannya. Jauh lebih baik untuk mengetahui hal ini dalam pengujian daripada setelah Anda ditayangkan.

Pengembang harus melakukan pengujian awal sehingga kami akan tahu bagian yang telah kami kodekan akan berfungsi seperti yang diharapkan untuk bekerja, sesuai dengan persyaratan yang kami dapatkan. Jadi kami telah melakukan pengujian normal serta menulis Tes Unit untuk kode yang telah kami tulis.

Langkah selanjutnya adalah pekerjaan QA untuk mencari tahu apa yang tidak dilihat pengembang ketika kami menulis kode. Pengembang berpikir di level yang lebih tinggi tetapi pengguna mungkin tidak berpikir di level yang sama. Ketika pengembang menguji karyanya dan harus memasukkan beberapa teks ke dalam kotak teks, ia mungkin selalu memasukkan pengguna yang berpikiran penuh akan melakukannya. Mungkin pengguna mungkin melakukannya juga, tetapi secara acak ketika ia memasukkan karakter khusus seperti% & $ ^ dalam teks dan yang merusak aplikasi itu tidak terlihat baik pada pengguna akhir. Pengembang tidak dapat dan tidak akan memikirkan semua kemungkinan yang bisa terjadi karena ia tidak terlatih untuk berpikir seperti itu. Ketika datang ke QA (tester) mereka selalu berpikir tentang apa yang mungkin dilakukan pengguna untuk merusak aplikasi ini dan mencoba setiap hal bodoh dalam buku ini, bukan pengguna yang bodoh tetapi kita tidak boleh membiarkan apa pun kebetulan.

Sekarang kita juga harus memahami bahwa pada umumnya ada lebih dari satu bagian yang dilakukan pada saat yang sama dan keduanya akan diproduksi. Pengembang hanya dapat menguji bagiannya dan berpikir bahwa itu berfungsi dengan baik tetapi pengujian regresi keseluruhan perlu dilakukan untuk semua bagian yang didorong serta untuk mengetahui bahwa kombinasi dari dua bagian yang berbeda dapat merusak aplikasi dan itu tidak tidak terlihat bagus juga. Kami juga harus mempertimbangkan skenario pengujian beban dan hal-hal lain yang lebih dikenal oleh para penguji.

Akhirnya kita harus melalui UAT (Tes Penerimaan Pengguna) untuk melihat apakah karya yang kita lakukan sesuai dengan yang diharapkan. Secara umum, meskipun persyaratan melewati BA, orang terakhir mungkin tidak tahu persis seperti apa rupanya dan dia mungkin berpikir itu tidak seperti yang mereka harapkan atau mereka mungkin ingin menambahkan sesuatu yang lain agar terlihat lebih baik atau karena alasan tertentu mereka mungkin membatalkan utuh karena mereka pikir potongan tidak akan pergi dengan fungsionalitas yang sudah tersedia.

Sebagaimana dijelaskan di atas, ini sangat penting dan tidak dapat dilakukan oleh pengembang sendiri dan sangat diperlukan agar aplikasi berfungsi dengan baik. Manajemen dapat mengatakan ini adalah pendekatan konservatif tetapi itu adalah pendekatan yang lebih baik. Kita dapat melakukan beberapa penyesuaian pada kata di atas tetapi tidak dapat menghindari secara keseluruhan.

Komentar di atas menimbulkan poin besar.

Satu tambahan yang tidak disebutkan sebelumnya adalah bahwa memiliki kode tes individu yang terpisah bertindak sebagai pemeriksaan tambahan pada persyaratan, dan jika sistem mengimplementasikannya dengan benar.

Persyaratan dan dokumentasi tidak sempurna, dan seringkali implementasi adalah hasil dari interpretasi persyaratan oleh pengembang.

Ketika pengujian dilakukan oleh individu yang terpisah, mereka juga memberikan interpretasi mereka sendiri tentang persyaratan saat membuat rencana pengujian dan melaksanakan tes.

Ketika kegiatan pengujian dilakukan secara independen dari kegiatan pengembangan, dan output dari kedua "setuju" itu memberikan konfirmasi tambahan bahwa sistem itu benar dan benar-benar cocok dengan maksud asli dari persyaratan.

Seorang programmer, ketika menguji, akan melihat kotak teks berlabel "Kuantitas" dan masukkan "1". Seorang programmer yang sangat berpengalaman kemudian akan melakukan tes tindak lanjut dengan nilai "2".

Seorang pengguna akan melihat kotak teks berlabel "Jumlah" dan masukkan "~~ ROX unicorn !!! ~~". Pengguna yang berpengalaman juga akan mencoba "-12 1/2".

Mudah-mudahan, seorang tester akan berada di sana di suatu tempat untuk memberi tahu programmer tentang apa yang akan dialami pengguna ketika mereka melakukan hal-hal ini.

Salah satu alasannya adalah karena pengembang terlalu dekat dengan kode mereka sendiri. Mereka tahu itu kebiasaan, itu perilaku aneh. Mereka cenderung menguji sekitar keanehan kecil yang mereka kenal dengan baik. Mereka tidak cukup objektif tentang hal itu. Tim uji memperlakukannya seperti kotak hitam. Mereka menulis matriks lusinan atau ratusan test case dan secara metodis menjalankannya untuk melihat apa yang akan dilakukan kode. Seringkali mereka membuat skenario yang tidak pernah diimpikan oleh tim pengembang.

Alasan lainnya adalah waktu. Untuk proyek-proyek besar yang dibangun secara bertahap, tim pengembangan akan membangun Tahap 1. Kemudian penguji akan mengujinya saat Tahap 2 sedang dibangun dan cacat Tahap 1 diperbaiki. Ini berlaku untuk semua tahap, jadi tahap yang diuji adalah yang sebelumnya dibangun.

Saya ingin mengumpulkan beberapa argumen mengapa membiarkan pengembang menguji pekerjaannya sendiri sebagai langkah terakhir sebelum tes masuk ke produksi adalah ide yang buruk, karena sayangnya, tempat kerja saya kadang-kadang melakukan ini (terakhir kali ini muncul , argumen itu bermuara pada kebanyakan orang yang terlalu sibuk dengan hal-hal lain dan tidak punya waktu untuk membuat orang lain terbiasa dengan bagian dari program tersebut - ini adalah perangkat lunak yang sangat khusus).

Tes tidak opsional untuk pengembang. Pengembang harus menguji kode yang ditulisnya. Bagaimana lagi dia bisa yakin, bahwa tugas itu telah berhasil diselesaikan? Anda harus menulis semacam tes otomatis (tidak terdaftar) atau melakukan pekerjaan pengecekan "apakah mesin melakukan apa yang saya inginkan" manuall (dengan menggunakan GUI, memanggil perintah pada baris perintah atau apa pun).

Segala sesuatu yang sedang diuji setelah itu adalah "hanya" pengujian tambahan oleh orang lain (rekan kerja, QA, ...). Tidak ada alternatif untuk pengujian langsung oleh pengembang. Setiap orang yang mengatakan kepada saya bahwa seorang pengembang tidak perlu menguji (atau bahkan tidak diizinkan) kode / fitur yang ia tulis hanya memiliki nol pemahaman tentang bagaimana perangkat lunak sedang dikembangkan.

Itu akan diuji oleh seseorang yang tidak terbiasa dengan kode apakah Anda suka atau tidak. Pertanyaannya adalah apakah Anda ingin seseorang menjadi pelanggan Anda.

Pertanyaan bagus Dalam situasi Anda, test case -sometimes- ada dan perangkat lunaknya tampaknya cukup kompleks sehingga mempercepat pemula pada produk tidak praktis. Anda juga mengatakan tes yang dilakukan adalah tes akhir sebelum produksi

Alasannya mungkin tidak apa-apa bagi pengembang untuk melakukan tes akhir

• Ada cukup cakupan tes lain ... Tes unit ada, lingkungan tes integrasi ada dan digunakan, pengujian UI, pengujian eksplorasi, dll. Telah dilakukan, dll. Kemudian tes akhir kurang kriteria penerimaan yang ketat daripada final " melintasi"
• Ada satu set kasus uji yang ditulis oleh SQA / Tester profesional bahwa seseorang (pengembang) dapat / perlu mengikuti secara eksplisit
• Risiko kegagalan fitur / produk / modul dinyatakan telah dikurangi ke tingkat rendah (biarkan profesional menguji area berisiko tinggi, dan "pemula" menguji risiko yang lebih rendah)
• Kenyataan dari situasi bisnis adalah bahwa melepaskan produk dengan potensi cacat lebih baik daripada menunda rilis
• Pengembang yang dimaksud sebenarnya adalah penguji yang sangat berkualitas juga dan mampu secara mental melakukan perubahan peran
• Perubahan adalah perbaikan bug yang dilakukan di lapangan oleh pengembang ketika situs pelanggan dimatikan atau kehilangan pendapatan karena sistem sedang offline (tambalan yang akan dibawa kembali ke kantor dan diuji / dirilis dalam versi terkontrol ASAP )

Alasan seorang pengembang seharusnya tidak melakukan pengujian

• Ada yang lain

Secara umum, sepertinya Anda berada di jalur yang benar untuk menyerang solusi nyata - Mintalah pakar SQA membuat Uji Kasus ...

Catatan: Saya umumnya mendukung membiarkan Pengembang melakukan pengujian, tetapi saya sangat yakin bahwa poin pertama ada ....

Manusia, sebagai manusia, cenderung menderita Bias Kognitif - di mana penilaian mereka dalam dua skenario yang hampir sama akan berbeda, hanya karena beberapa hal yang telah berubah - satu hal yang saya perhatikan dalam 8 tahun pembangunan, adalah ketika pengembang dihadapkan dengan pengujian kode sendiri, sebagai lawan dari kode yang ditulis seorang rekan, pengujian yang dilakukan pada kode mereka sendiri jauh lebih buruk kualitasnya.

Ini bukan untuk mengatakan bahwa pengembang salah secara langsung - otaknya akan menggunakan bias yang mereka tulis itu, untuk memperkuat fakta bahwa mereka percaya itu benar, dan hanya akan melakukan pemeriksaan dasar, sebagai lawan dari pengembang yang melihat kode orang lain, akan melakukan banyak pemeriksaan lebih menyeluruh.

Ada ribuan contoh di luar sana di mana prosedur telah diberlakukan untuk mencegah bias kognitif, atau yang biasa dikenal dengan "The Human Factor", seperti sistem terkomputerisasi dalam kontrol lalu lintas udara, untuk mencegah dua pesawat berbeda yang menempati wilayah udara yang sama pada saat yang sama. waktu, untuk prosedur medis diberlakukan sehingga lebih dari satu dokter harus memberikan diagnosis.

Sudah saatnya industri TI bergerak ke arah sikap yang lebih profesional dan menerapkan prosedur untuk mencegah pengujian kode Anda sendiri.

• Eeveryone harus menguji - Kode uji develpers, fungsionalitas uji QA'ers, pesan tes pemasaran. Dengan cara itu semua orang berbagi filosofi dan bahasa yang sama di sekitar pengujian yang merupakan setengah pertempuran.

• Pengujian adalah perawatan rutin dan saya biasanya menggunakan analogi untuk membandingkan . Misalnya analogi ganti oli mobil. Anda tidak pernah 'harus' mengganti oli Anda. Tetapi Anda tetap melakukannya secara teratur. Sama untuk menyikat gigi. Ada alasan Anda mempertahankannya setiap hari - mereka tidak akan merusak 'hari ini', ini semua tentang hari esok dan hari-hari mendatang dan melakukan investasi.

• Setiap orang harus berbagi tanggung jawab untuk menguji. Tim QA penting, namun menjadikan "pengujian" sebagai sesuatu yang hanya dilakukan oleh tim QA yang menjadikannya sebagai aktivitas 'terpisah' yang tidak diintegrasikan dengan pengembangan produk dan alur kerja yang bukan hal yang baik.

• Ketika sesuatu yang pernah rusak dalam produksi melakukan dua hal:

  1. Katakan "hmm, apakah kita memiliki tes untuk itu " sebagai komentar pertama.
  2. Lakukan perbaikan termasuk tes untuk masalah , pertama yang mereproduksi, daripada perbaikan.

Di perusahaan saya, kami membangun beberapa aplikasi keuangan yang cukup rumit. Kebijakan umum kami adalah pengembang harus memastikan tidak ada kesalahan teknis yang muncul. Pada dasarnya, cobalah semua yang Anda bisa untuk mematahkannya, mengingat sumber daya pengguna. Ketika Anda tidak dapat menemukan kesalahan runtime, kirimkan itu ke BA untuk pengujian. Kami memiliki beberapa pengembang yang tersesat dalam pengujian persyaratan bisnis hingga titik habis, tetapi hanya karena semua pengujian itu bukan tanggung jawab mereka. Kecuali jika ada beberapa kesalahan mencolok yang terlihat jelas, kami mengirimkannya kepada orang-orang yang dibayar untuk memahami hasilnya. Selain itu, pengguna harus memiliki peran nyata dalam memverifikasi hasil. Petugas penjualan di toko ritel tidak mencoba pakaian untuk Anda, mereka hanya membantu Anda dengan "detail teknis" seperti menemukan pakaian dengan ukuran yang tepat.

Salah satu masalah adalah pengembang memiliki sedikit insentif untuk memecahkan kode mereka sendiri - beberapa orang bersedia untuk mencari cacat dalam karya mereka sendiri atau bersedia membuat kesalahan. Memiliki tim yang terpisah membantu memastikan bahwa segala sesuatunya akan rusak.

Peran Penjaminan Mutu sangat penting, antara lain, agar seseorang dapat memeriksa bahwa pengembang telah memahami persyaratan. Pengembang tidak dapat melakukan pemeriksaan ini sendiri karena jika mereka pikir mereka salah paham yang akan meminta klarifikasi.