Haruskah pengembang juga bertindak sebagai penguji? [Tutup]


60

Kami adalah tim scrum dari 3 pengembang, 1 desainer, master scrum, dan pemilik produk. Namun, kami tidak memiliki penguji resmi di tim kami. Masalah yang selalu ada pada kami, adalah bahwa, menguji aplikasi dan melewati tes-tes tersebut dan menghilangkan bug telah didefinisikan sebagai salah satu kriteria untuk mempertimbangkan PBI (Product Backlog Item) yang dilakukan.

Tetapi masalahnya adalah, tidak peduli berapa banyak kita (3 pengembang dan 1 desainer) mencoba menguji aplikasi dan menerapkan kasus penggunaan, masih ada beberapa bug yang tidak terlihat dan merusak presentasi kita ( hukum Murphy ) kepada para pemangku kepentingan.

Sebagai obat, kami merekomendasikan agar perusahaan menyewa tester baru. Seseorang yang pekerjaannya akan menguji, dan hanya menguji. Penguji profesional resmi.

Namun, masalahnya adalah bahwa, scrum master dan pemangku kepentingan percaya bahwa pengembang (atau perancang) juga harus menjadi penguji.

Apakah mereka benar Haruskah kita pengembang (juga desainer) menjadi penguji juga?


1
Kemungkinan duplikat dari programer.stackexchange.com/questions/100637/… , meskipun itu diminta dari sudut pandang yang berbeda.
Adam Lear

Di tim scrum tempat saya berada, semua dari mereka sedang menguji aplikasi smartphone atau tablet dan semuanya sangat membantu.
ott--

Penulis membutuhkan editor.
JeffO

Jawaban:


59

Ex ante: Tampaknya ada banyak kebingungan tentang apa yang dianggap sebagai pengujian apa yang tidak. Tentu, setiap pengembang perlu menguji kodenya saat ia membuatnya, ia perlu memverifikasinya berfungsi. Dia tidak bisa menyerahkannya ke penguji sebelum dia pikir itu dilakukan dan cukup baik. Tetapi pengembang tidak melihat semuanya. Mereka mungkin tidak mengenali bug. Bug ini hanya dapat ditemukan kemudian dalam siklus pengembangan ketika pengujian menyeluruh dilakukan. Pertanyaannya adalah apakah pengembang harus melakukan pengujian semacam itu atau tidak, dan menurut pendapat saya yang sederhana ini perlu dilihat dari sudut pandang manajer proyek:

Pengembang bisa menjadi penguji, tetapi mereka seharusnya tidak menjadi penguji . Pengembang cenderung secara tidak sengaja / tidak sadar menghindari untuk menggunakan aplikasi dengan cara yang dapat merusaknya. Itu karena mereka menulisnya dan sebagian besar mengujinya dengan cara yang seharusnya digunakan.

Penguji yang baik di sisi lain, mencoba menyiksa aplikasi. Niat utamanya adalah untuk melanggarnya. Mereka sering menggunakan aplikasi dengan cara yang tidak dibayangkan oleh pengembang. Mereka lebih dekat ke pengguna daripada pengembang dan sering kali memiliki pendekatan yang berbeda untuk menguji alur kerja.

Juga, menggunakan pengembang sebagai penguji meningkatkan biaya pengembangan dan tidak menguntungkan kualitas produk sebanyak memiliki penguji khusus. Saya tidak akan membiarkan pengembang menguji coba karya mereka ketika saya bisa melakukannya dengan lebih baik oleh tester dengan harga murah. Hanya jika loop umpan balik antara pengembang dan penguji menjadi terlalu mahal, saya akan meminta pengembang saling silang kode, tetapi dalam pengalaman saya yang jarang terjadi dan sangat tergantung pada proses.

Itu tidak berarti pengembang harus ceroboh dan menyerahkan semuanya kepada tester. Perangkat lunak harus didukung oleh tes unit dan kesalahan teknis harus dikurangi seminimal mungkin sebelum menyerahkan perangkat lunak ke tester. Namun, kadang-kadang Anda harus memperbaiki di sini, memecahkan masalah di sana atau bug lain yang tidak dapat dilihat oleh pengembang, itu tidak masalah. Juga, pengujian integrasi sebagian besar harus dilakukan oleh pengembang. Tujuan utama penguji adalah untuk memverifikasi bahwa persyaratan dipenuhi.

Dalam tim sekecil itu (dan juga tergantung pada ukuran aplikasi), saya juga dapat melihat tester dalam peran hibrid, tes unit penulisan, dan tes UI. Anda pasti harus menyewa satu .

Tetapi yang lebih penting dari tester adalah pembekuan / cabang biasa. Jangan tampilkan apa pun yang belum diuji dengan benar. Ketika Anda telah menambahkan fitur atau mengubah sesuatu, semua yang ada di sekitarnya harus diverifikasi lagi. Anda hanya akan mendapatkan reputasi yang buruk jika perusahaan Anda tidak. Jangan melepaskan sesuatu yang tidak stabil. Ketika pelanggan ingin memiliki perangkat lunak pada tanggal tertentu, kemudian berhenti mengembangkannya cukup awal dan mengujinya dengan benar, sehingga Anda memiliki cukup waktu untuk perbaikan bug. Seringkali lebih baik menolak permintaan fitur menit terakhir daripada mengimplementasikannya dengan buruk atau rilis tanpa pengujian yang tepat.


9
Sangat dan sangat tidak setuju ... Pengembang dapat menjadi penguji yang sangat efektif tetapi pengembang fitur TIDAK juga harus menjadi penguji fitur yang sama. Banyak tim kecil memainkan kedua peran, oleh tiga orang yang bekerja pada tiga fitur yang berbeda, kemudian memberikan pengujian kepada salah satu dari tiga pengembang lainnya. Ini bekerja sangat baik ketika tim tidak memiliki tester QA.
maple_shaft

5
@maple_shaft: Saya tidak punya alasan untuk tidak memiliki tester. Setiap proyek akan memberikan kualitas yang lebih tinggi dengan tester khusus dan pengembang dapat fokus, berkembang dengan baik jika ada. Memiliki pengembang menguji satu sama lain kode adalah solusi darurat, bahkan untuk tim kecil imho. Anda harus membaca artikel Joel tentang itu juga.
Falcon

3
Pengembang bisa menjadi penguji - dan pengembang yang baik benar-benar tahu banyak tempat di mana kode bisa lemah dan dapat rusak. Tidak pernah ada orang yang menguji kode yang mereka desain atau tulis - itu tidak berguna. Kode orang lain mungkin ok.
StasM

4
@deadalnix: Ini benar-benar membingungkan saya mengapa orang downvote tanpa membaca dan memahami jawaban saya. Mengutip diri saya sendiri: "Perangkat lunak harus didukung oleh unit test dan kesalahan teknis harus dikurangi seminimal mungkin sebelum menyerahkan perangkat lunak ke tester."
Falcon

2
"Sebaliknya, seorang penguji yang bagus, mencoba menyiksa aplikasi. Niat utamanya adalah untuk melanggarnya." - Sepenuhnya tidak setuju. Saya memiliki tester yang terus-menerus mencoba untuk menidurkan keyboard ke bawah, atau bidang meluap. Tentu, ini adalah bug, tetapi faktur $ 1 triliun triliun yang menimbulkan kesalahan sangat rendah pada daftar tugas saya hingga tidak mendaftar. Sebuah BESAR tester menguji semua skenario bahwa berbagai pengguna akan menggunakan aplikasi. Pengembang yang baik memastikan semua jalur kode telah diuji dan aplikasi berfungsi saat digunakan sebagaimana dimaksud.
Paul

42

Pengembang dapat menjadi penguji - dari kode pengembang lain.

Tetapi menguji kode Anda sendiri bukanlah langkah yang baik - pengembang cenderung memiliki mental block tentang kode mereka sendiri, dan karenanya mengalami kesulitan dalam mendesain tes komprehensif atau yang sesuai.

Akan selalu ada pengembang yang berpikir mereka melakukan ini dengan baik, tetapi biasanya mereka tidak (dan saya yakin tahu saya memiliki banyak titik buta).

Jika Anda BENAR-BENAR TIDAK BISA menyewa seorang tester, maka dapatkan pengembang untuk saling menguji pekerjaan silang - yaitu, jika A menulis kode dan melakukan tes unit, maka dapatkan B untuk memeriksa tes unit tersebut dan melihat apakah ada hal lain yang dapat ditambahkan. . Dan dapatkan B untuk mencoba dan menguji kode (sebagai pengguna) dan melaporkan cacat.

Ini tidak sempurna tetapi lebih baik daripada satu pengembang yang mencoba melakukan segalanya.

Terkadang kolega Anda dapat benar-benar hebat dalam merusak perangkat lunak Anda, karena mereka mendapatkan kesenangan dari itu dan tidak terlalu peduli - karena itu bukan kode MEREKA.


2
Oh ya tentu. Sangat setuju. Hanya saja ketika Anda tidak bisa mendapatkan 100% dari apa yang Anda inginkan, Anda mungkin harus puas. Anda tahu bahwa kurang itu tidak begitu baik tetapi lebih baik daripada tidak sama sekali.
cepat_now

4
Saya umumnya setuju dengan pengujian silang tetapi pada beberapa tim yang akan menimbulkan konflik. Beberapa orang senang menyalahkan orang lain ("barang saya berfungsi, barang Anda tidak, lol, saya jauh lebih baik daripada Anda") dan itu tidak dapat diterima. Saya sudah menyaksikannya berkali-kali. Crosstesting hanya boleh dilakukan antara kolega yang saling menghormati. Di tim saya, saya telah memperkenalkan pengembang tanpa nama yang disalahkan untuk setiap bug untuk menghindari siapa pun kehilangan wajahnya. Bug tidak bernama, itu terjadi.
Falcon

5
+1 tidak mungkin untuk menguji kode Anda sendiri dengan benar. Sungguh menakjubkan trik mana yang dapat dimainkan pikiran pada Anda - Anda akan 100% yakin Anda membuat kode dan menguji beberapa fungsi dan itu akan membawa orang lain untuk menunjukkan kepada Anda itu sebenarnya tidak berfungsi kecuali dalam kasus yang sangat sempit dan itu akan menjadi jelas untuk Anda sekali ditampilkan - tetapi Anda tidak akan pernah melihatnya sendiri. Pikiran menggunakan jalan pintas kognitif, dan dalam menguji itu membuat mustahil bagi orang yang merancang dan mengembangkan kode untuk mengujinya dengan benar.
StasM

2
@StasM - setuju, dengan satu kualifikasi kecil: Saya telah menemukan bahwa kembali ke kode saya sendiri beberapa bulan kemudian, saya dapat melihat kesalahan dan dapat melakukan pekerjaan yang lebih baik dengan mengujinya secara objektif. Tetapi menguji sendiri setelah menulis memang sangat sulit.
cepat_now

1
@ Ben Aston: Pengembang harus tetap melakukan tes unit, tes integrasi, dll. Hanya tidak secara eksklusif. Bintik-bintik buta tidak akan hilang hanya karena Anda menginginkannya.
cepat_now

11

Haruskah jurnalis cenderung menulis dengan benar? Maksud saya, itu adalah tugas korektor dan editor untuk menemukan semua kesalahan tata bahasa.

Meskipun demikian, jurnalis memberikan beberapa mantra untuk mereka sendiri. Meskipun demikian, korektor adalah profesi yang terpisah dan penting.

Hal yang sama tentang pengembang dan penguji, kecuali fakta bahwa QA adalah bagian yang lebih penting dari pengembangan. Bahkan jika Anda adalah pengembang yang baik, Anda tidak punya waktu untuk menguji secara menyeluruh semua kasus uji, untuk mencakup semua lingkungan, browser, OS yang didukung produk Anda.

Jika seseorang, selain berkembang, terus melakukan pekerjaan itu juga, itu hanya berarti fakta sederhana - ia adalah penguji paruh waktu.


10

tidak peduli berapa banyak kami (3 pengembang dan 1 desainer) mencoba menguji aplikasi dan menerapkan use case, masih ada beberapa bug yang tidak terlihat dan merusak presentasi kami ... kepada para pemangku kepentingan.

Pertimbangkan untuk melakukan "lari terkontrol" untuk satu atau dua sprint, lacak dev dan upaya pengujian secara terpisah. Di akhir proses tersebut, analisis data yang dikumpulkan untuk mengetahui berapa banyak upaya yang Anda habiskan untuk pengujian.

Jika Anda mengetahui bahwa pengujian membutuhkan banyak upaya, sampaikan data itu ke manajemen - itu akan menjadi bukti kuat yang mendukung permintaan Anda (jauh lebih menarik dari yang Anda miliki sekarang).

Jika tidak (jika Anda merasa pengujian Anda hanya membutuhkan sedikit waktu), pertimbangkan untuk menginvestasikan upaya tambahan untuk melakukannya dengan lebih baik (atau belajar cara melakukannya). Negosiasikan upaya tambahan yang Anda rencanakan dengan manajemen Anda - karena mereka mungkin lebih suka menyewa tester. :)


... kami menyarankan agar perusahaan menyewa tester baru. Seseorang yang pekerjaannya akan menguji, dan hanya menguji. Penguji profesional resmi.

Namun, masalahnya adalah bahwa, scrum master dan pemangku kepentingan percaya bahwa pengembang (atau perancang) juga harus menjadi penguji.

Harus saya akui, manajemen perusahaan Anda terlihat sangat lemah bagi saya. Maksudku - ok, mungkin benar-benar sulit untuk mengetahui berapa banyak penguji yang terbaik untuk proyek ini, oke.

Tetapi untuk memiliki setidaknya satu tester hanyalah taruhan yang aman - benar-benar lucu bahwa mereka ragu untuk mencobanya, sambil mengklaim diri mereka scrum / gesit .


9

Kami memiliki dua pengembang uji silang setelah yang pertama membuat beberapa perubahan pada layar entri. Saat itulah tester reguler kami libur cuti hamil.

Dia pada dasarnya mengubah layar Daftar Faktur yang digunakan pengguna untuk memilih faktur sebelum memperbesar untuk melakukan pengeditan melalui tombol "Edit". Daftar asli dibuang dan gridview baru dimasukkan, dengan penyaringan, pengelompokan, pengurutan dan segala macam fungsi keren.

Pengujian berjalan hebat dan mereka mengunggah perubahan ke pelanggan pada hari berikutnya. Dua minggu kemudian, pelanggan menelepon dan berkata, "Kami benar-benar menyukai barang baru yang Anda masukkan, kami dapat melihat semua jenis informasi sekarang. Tapi ... er ..... ke mana kita pergi untuk mengedit faktur sekarang? ?? "

Ternyata pengembang mengeluarkan kotak centang (untuk pemilihan) dan tombol edit dan karena pengembang selalu mengklik dua kali untuk memilih item, tidak ada dari mereka yang menemukan ada yang salah dengan itu ......

Pengembang dan pengguna tinggal di dunia yang berbeda, memiliki pengujian silang lebih baik daripada pengembang menguji pekerjaannya sendiri tetapi masih belum sama.


3
Saya tidak akan mengatakan "mereka hidup di dunia yang berbeda", tetapi orang memiliki kebiasaan dan kode pengembang akan berfungsi jika itu akan digunakan oleh seseorang dengan kebiasaan yang sama. Saya tidak dapat menghitung seberapa sering saya tidak dapat mereproduksi bug yang ditemukan oleh seorang penguji, melihat dari balik bahunya ketika dia mereproduksi bug, dan berkata, "wow, saya tidak akan pernah melakukan apa yang baru saja Anda lakukan".
gnasher729

4

Seperti yang orang lain katakan di sini, para pengembang dapat menguji-silang kode masing-masing (pengujian unit atau fungsional), dan mungkin master scrum dan pemilik produk Anda dapat membantu dengan pengujian integrasi, tetapi untuk pengujian penerimaan pengguna Anda harus memastikan Anda mendapatkan banyak umpan balik dari pengujian pelanggan - yang berarti penyebaran yang sering mereka dapat lakukan dengan cara yang dilakukan pengguna nyata dan saluran komunikasi yang benar - benar terbuka .


2

Anda harus mendesain dengan testabilitas, tetapi jika Anda tidak memiliki tester khusus maka beberapa hal hanya akan lolos dari keretakan karena tidak ada cukup waktu dalam sehari untuk mendesain, mengimplementasikan, dan menguji perangkat lunak.


2

Perangkat lunak pengujian adalah pekerjaan profesional penuh waktu. Perlu otak yang baik, bakat, dan banyak pengalaman untuk menjadi penguji yang baik. Menganggap bahwa pengembang perangkat lunak, betapapun pintarnya, dapat mendekati penguji profesional ketika pengujian hanyalah komponen kecil dari pekerjaan sehari-harinya.

Selain itu muncul masalah yang secara tidak sadar pengembang perangkat lunak tidak ingin menemukan bug.


1

Saya setuju dengan poin mereka bahwa pengembang / desainer harus menguji kode mereka, dengan cavaet bahwa desainer / pengembang yang melakukan bagian kode tidak menjadi satu-satunya "mata" pada kode itu sebelum berkomitmen untuk hidup. Meskipun itu tidak akan mengambil semuanya, setidaknya akan membantu untuk menghindari kebutaan yang merayapi pengujian dan pengujian ulang kode Anda sendiri saat mengembangkan.

Dari menyebutkan use case, saya akan menganggap bahwa Anda juga menggunakan alat cakupan kode? Jika tidak, ini bisa membantu melihat kode apa yang mungkin tidak diuji, dan bisa muncul dalam bug yang tidak terduga selama kondisi tertentu.

Yang sedang berkata, jika ada cukup banyak pekerjaan atau organisasi Anda adalah ukuran yang layak, saya akan setuju bahwa orang QA profesional diperlukan, akan membantu untuk memfokuskan peran semua orang sedikit lebih, dan mereka juga dapat melihat apakah ada pola seperti apa sedang dilewatkan, dan yang lebih penting, bagaimana cara memperbaikinya.

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.