Haruskah pengembang terlibat dalam fase pengujian?


10

kami menggunakan proses pengembangan berbentuk V klasik. Kami kemudian memiliki persyaratan, arsitektur, desain, implementasi, tes integrasi, tes sistem dan penerimaan.
Penguji sedang mempersiapkan kasus uji selama fase pertama proyek. Masalahnya adalah, karena masalah sumber daya (*), fase pengujian terlalu panjang dan sering diperpendek karena kendala waktu (Anda tahu manajer proyek ...;)). Pengembang melakukan tes unit sebagaimana mestinya.

Jadi pertanyaan saya sederhana: apakah pengembang harus terlibat dalam fase pengujian dan bukankah terlalu 'berbahaya'. Saya khawatir itu akan memberikan manajer proyek perasaan palsu kualitas yang lebih baik karena pekerjaan telah dilakukan tetapi apakah orang yang ditambahkan. Hari akan bernilai? Saya tidak terlalu yakin pengembang melakukan tes (jangan tersinggung di sini, tetapi kita semua tahu itu cukup sulit untuk istirahat dalam beberapa klik apa yang telah Anda buat dalam beberapa hari).

Terima kasih telah berbagi pemikiran Anda.

(*) Untuk alasan yang tidak jelas, meningkatkan jumlah penguji bukanlah suatu pilihan pada hari ini.

(Hanya dimuka, itu bukan duplikat Haruskah programmer membantu penguji dalam merancang tes? Yang berbicara tentang persiapan pengujian dan bukan pengujian pelaksanaan, di mana kita menghindari implikasi dari pengembang)


Diedit untuk tepat bahwa pengembang kami sedang melakukan tes unit mereka. Saya khawatir tentang fase setelah unit test, ketika orang-orang QA masuk dalam loop.
LudoMC

Hmmm, tidak akan mudah untuk memilih antara "YA mutlak tegas" dan "sama sekali tidak". Akan memikirkannya sedikit lagi, menunggu jawaban lain atau komentar pada jawaban untuk memiliki pandangan yang lebih jelas.
LudoMC

Oke, saya menerima satu jawaban tetapi juga memilih beberapa jawaban lain yang memberikan argumen bagus untuk masalah ini. Terimakasih untuk semua.
LudoMC

Jawaban:


13

Melihat pertanyaan Anda secara harfiah ("terlibat dalam") Satu-satunya jawaban saya adalah mutlak tegas

IYA

Devs seharusnya tidak pernah memiliki keputusan akhir pada kode mereka sendiri .

Tapi, Devs harus terlibat dalam pengujian pekerjaan devs lain. Ia melakukan dua hal:

  1. Ini membawa wawasan pengembang ke pengujian. Ini baik dari kasus umum hanya mengetahui apa API yang mungkin digunakan pada titik tertentu, apa pengecualian yang mungkin berasal dari API tersebut, dan bagaimana mereka harus ditangani. Ini juga membantu pada proyek tertentu karena para pengembang mendapatkan lebih banyak paparan berbagai diskusi tentang mengapa sesuatu dilakukan daripada biasanya QA, yang berarti mereka dapat menemukan kasus-kasus tepi yang QA tidak. Bug yang ditemukan oleh seorang dev juga cenderung lebih murah untuk diperbaiki karena seorang dev biasanya akan memberikan lebih banyak informasi dan lebih banyak wawasan tentang bagaimana memperbaikinya segera.
  2. Ini memberikan dev dev ke bagian-bagian dari aplikasi yang mungkin tidak mereka dapatkan. Ini akan membuat mereka menjadi pengembang yang lebih baik untuk aplikasi itu dalam jangka panjang. Ketika saya tahu bagaimana API saya dikonsumsi, saya jauh lebih baik dalam mengantisipasi hal berikutnya yang harus saya lakukan daripada jika saya hanya mengusir spec. Yang paling penting, saya bisa tahu kapan spesifikasi itu salah sebelum saya mulai coding jika saya tahu aplikasi dan penggunaannya.

Akhirnya, mengapa Anda tidak menggunakan mata sebanyak mungkin? Anda jarang bisa melewati proses perekrutan dan on-boarding untuk membawa orang-orang QA tambahan untuk waktu krisis. Jadi, di mana Anda menemukan mata ekstra yang Anda butuhkan? Atau apakah Anda mencoba untuk melewati waktu krisis dengan jumlah QA yang sama dengan yang pernah Anda alami? Bahkan jika para pengembang menghabiskan 20% dari waktu pengujian mereka dan 80% memperbaiki bug apa pun yang muncul, masih lebih banyak penglihatan pada aplikasi daripada yang Anda miliki sebelumnya. Pengujian otomatis hanya memberi Anda tingkat jaminan tertentu dan tidak akan pernah 100%.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29


+1 karena pengembang harus terlibat dalam melihat kode orang lain
Gary Rowe

Saya akan menerima yang ini karena 1 - tautan yang disediakan (sangat menarik dan terkait erat dengan situasi kami) 2 - argumen yang baik dalam jawaban Anda: fakta bahwa pengembang tidak boleh menguji kode mereka sendiri, bahwa itu memberi mereka pandangan yang baik bagian lain dari aplikasi atau sistem.
LudoMC

11

Untuk apa pun kecuali pengujian Unit, sama sekali tidak. Pengembang hanya tahu terlalu banyak tentang aplikasi dan bagaimana "seharusnya" bekerja menjadi penguji obyektif.


2
Sebagian besar, saya sepenuhnya setuju dengan ini. Namun, pos tersebut mengatakan bahwa tim QA bertanggung jawab untuk membuat kasus uji. Dengan asumsi tes memiliki cakupan menyeluruh, saya tidak melihat alasan kuat mengapa pengembang tidak dapat menjalankan kasus uji sebelum merilis perangkat lunak ke QA. Mungkin membantu menangkap bug lebih awal dan mengurangi overhead yang dihasilkan dari beberapa rilis perbaikan bug.
Pemdas

2
Saya tidak setuju dengan sudut pandang ini karena memiliki mata pengembang dapat sangat bermanfaat selama pengujian fungsional. Pengembang adalah sumber daya yang berharga sehingga tidak harus melalui skenario tes hafalan, melainkan mereka dapat memberi tahu penguji ke mana harus pergi untuk memecahkan aplikasi lebih efisien (membuat hidup penguji lebih menyenangkan ...)
Gary Rowe

GR ... umumnya saya setuju dengan pernyataan Anda tentang pengembang untuk menghargai sumber daya, tetapi masalah di sini sebenarnya adalah mengatur ulang sumber daya apa yang telah mereka miliki untuk memastikan cakupan pengujian yang memadai. Jika ini berarti bahwa para pengembang harus terlibat dalam beberapa pengujian Qaish, maka jadilah itu.
Pemdas

8

Perbedaan mendasar dalam filosofi pengujian antara pengembang dan Qs adalah ini: programmer biasanya menguji programnya untuk membuktikan bahwa kodenya berfungsi (pengujian "positif"). QA dapat dan memang melakukan ini, tetapi juga memiliki fokus tambahan untuk mencari tahu apa yang tidak berhasil dengan mencoba memecahkan perangkat lunak (menggunakan pengujian "negatif").

Sejauh staf QA berpotensi rusak oleh pengujian programer yang "membuktikan" bahwa perangkat lunak bekerja, harus ada isolasi antara pengujian pengembang dan pengujian QA. Pengembang pasti dapat membantu pengujian QA bersama dengan menunjukkan apa yang berhasil, tetapi terserah QA untuk memverifikasi secara independen bahwa perangkat lunak tidak rusak.

Hal terbaik yang dapat dilakukan oleh programmer untuk membantu upaya pengujian adalah menyediakan rangkaian pengujian unit yang komprehensif, berkualitas tinggi, dan dapat diverifikasi, yang berisi tes yang selaras dengan kebutuhan individu dalam dokumen persyaratan.


2

Nah dari segi pengujian, ada 3 jenis.

Kotak hitam, kotak abu-abu, dan kotak putih.

Kotak hitam mengacu pada pengguna yang menguji produk, tanpa pengetahuan tentang bagaimana produk bekerja secara internal.

Kotak abu-abu mengacu pada pengguna yang memiliki pengetahuan tentang pemrograman komputer, tetapi tidak berada di tim pengembangan. Orang-orang ini akan menguji apakah produk mengalami kebocoran memori, masalah persyaratan sistem, dan sebagainya.

Inilah bagian utamanya: Kotak putih mengacu pada pengembang yang menguji produk pada level kode. Ini berarti mengatakan bahwa mereka melakukan pengujian unit, debugging, ... dll.

Oleh karena itu baik bahwa pengguna dan tim pengembangan semua terlibat dalam fase pengujian, tetapi masing-masing pengujian memerlukan tingkat komitmen yang sesuai dari pengguna dan tim pengembangan, tergantung pada apa yang diuji.


2

UNIT TESTING adalah keharusan bagi semua pengembang

Untuk informasi tentang bagaimana ini dapat digunakan untuk keuntungan Anda, baca tautan berikut jika Anda tertarik pada pengembangan C ++:

TIDAK ADA CARA ORANG QA BISA MELAKUKAN UJI INI. TIDAK MUNGKIN.


Saya setuju tetapi saya mengajukan pertanyaan sebaliknya. Haruskah pengembang dilibatkan dalam pengujian (tidak termasuk pengujian unit) di mana biasanya hanya orang-orang QA yang terlibat.
LudoMC

1

Dengan asumsi bahwa proyek tersebut memiliki sejumlah pengembang yang signifikan, maka tentu saja para pengembang harus mengerjakan pengujian. Satu peringatan adalah bahwa pengembang tidak mengerjakan pengujian (ini tidak termasuk pengujian unit) untuk kode mereka sendiri.


+1 untuk pengembang yang tidak menguji kode mereka sendiri (atau setidaknya tidak sendiri)
LudoMC

0

Saya lebih suka melihat staf administrasi (atau pengguna potensial aktual) melakukan pengujian QA daripada pengembang. Seseorang yang tidak tahu bagaimana produk itu dirancang untuk bekerja, perlu mencoba menggunakannya. Pengembang cenderung sangat terbatas dalam cara mereka mendekati pengujian dan terus terang mereka terlalu mahal per jam untuk digunakan untuk pengujian QA juga.


0

Anda menulis:

Masalahnya adalah bahwa, karena masalah sumber daya (*), fase pengujian terlalu panjang dan sering diperpendek karena kendala waktu. Itu karena pengembang tidak melakukannya. Salah satu perusahaan Internet terbesar yang memberikan produk paling stabil terbaik tidak menggunakan penguji sama sekali. Mereka hanya menggunakan pengujian otomatis, semua dilakukan oleh pengembang sendiri. Hasilnya adalah produk x10 yang lebih baik daripada saat pengembang meninggalkan pengujian ke "penguji".

Ini seperti memiliki pekerja konstruksi membangun rumah Anda, tetapi memiliki tim yang berbeda memastikan bahwa bangunan itu benar-benar berdiri, pintu-pintu terbuka dan tertutup, pendingin udara berfungsi dll. Mungkin perlu waktu x10 untuk membangun gedung, dan sebagian besar akan berakhir tidak bisa diandalkan.

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.