Haruskah pengembang juga bertindak sebagai penguji? [Tutup]

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?

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.

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.

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.

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 .

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.

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 .

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.

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.

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.