Bagaimana cara membuat tes otomatis populer? [Tutup]

Basis kode kami berkembang selama 20 tahun sekarang. Kami sekitar 10 devs + sqa bekerja dengan 500kloc. Beberapa waktu yang lalu tim kecil kami (2 devs, satu dari sqa) mulai mengerjakan program pengujian otomatis. Saat ini sekali jalan membutuhkan waktu 11 jam dan entah bagaimana merupakan tes integrasi. Kami sedang mengusahakannya untuk menurunkan ini dan mengurangi positif palsu dan membuat kemajuan yang baik dalam hal itu. Tetapi detail seharusnya tidak masalah.

Ini berfungsi dengan baik dan kami terus meningkatkannya. Kami (tim kecil) sangat menyukainya. Jika kita memecahkan sesuatu, kita perhatikan sehari kemudian dan tidak 2 bulan kemudian ketika sqa memeriksanya. Juga, manajer kami (dev + sqa) menyukai gagasan itu. Tetapi orang lain dalam tim mengabaikan hasil tes. Dalam pikiran mereka, jika tes gagal setelah checkin, itu masalah tes dan bukan perubahan kode dan itu hanya proyek mainan kami. Kami telah berdiskusi beberapa kali jika tes gagal adalah kesalahan nyata. Seringkali.

Kami tidak bisa dan tidak ingin menegakkan sesuatu. Bagaimana kita dapat menunjukkan bahwa pengujian otomatis adalah sesuatu?

Penolakan

Walaupun saya mungkin terdengar seperti seorang manajer, saya menulis ini sebagai pengembang yang juga perlu diyakinkan bahwa tes otomatis itu baik.

Anda harus memahami psikologi dasar pengembang. Merupakan kebutuhan yang sudah tertanam dari pengembang untuk melakukan kode. Apa pun yang mencegah mereka melakukannya adalah hal yang sangat, sangat buruk. Tes gagal jelas merupakan sesuatu yang mencegah mereka melakukannya, ergo itu adalah hal yang buruk. Karena itu perlawanan.

Apa yang harus Anda tunjukkan adalah bahwa, sementara tes otomatis memperlambat mereka dalam jangka pendek, dalam jangka panjang itu akan menyelamatkan mereka dari banyak kesedihan dan benar-benar akan mempercepat mereka, karena mereka akan dapat lebih fokus pada pengembangan hal-hal baru, dan akan kehilangan lebih sedikit waktu untuk melakukan hal lain yang tidak disukai pengembang: memperbaiki bug.

Dan ya, Anda harus menegakkannya. Anda harus mendapatkan dukungan tanpa syarat dari manajemen dan membuat penulisan tes otomatis wajib dan tidak dapat dinegosiasikan. Seiring waktu, para pengembang akan terbiasa dengan mereka. Apa yang akan membantu adalah jika Anda dapat menyusun beberapa metrik yang akan menunjukkan berapa banyak lagi pengembangan baru yang dilakukan, dan seberapa banyak jumlah bug yang berkurang sejak Anda memperkenalkan tes otomatis. Kata-kata tidak stabil. Angka-angka itu padat. Dan angka adalah sesuatu yang dipahami oleh pengembang rata-rata lebih baik daripada kata-kata. Jika Anda dapat membuktikan menggunakan angka solid bahwa tes otomatis bagus, Anda akan mendapatkan sedikit atau tidak ada perlawanan terhadapnya.

Dalam pikiran mereka, jika tes gagal setelah checkin, itu masalah tes dan bukan perubahan kode dan itu hanya proyek mainan kami. Kami telah berdiskusi beberapa kali jika tes gagal adalah kesalahan nyata. Seringkali.

Itu masalahnya. Jika tes Anda tidak jelas (bahkan jika itu dapat diandalkan 'sebagian besar waktu'), maka orang akan cenderung mengabaikan hasilnya. Tim otomasi Anda harus fokus pada menghilangkan negatif palsu itu. Hanya dengan demikian tim yang lain akan mendapatkan kepercayaan yang cukup pada hasil untuk benar-benar mempercayai mereka.

Kami tidak bisa dan tidak ingin menegakkan sesuatu.

Anda pasti harus menegakkannya! Jika seseorang mendorong kode baru dan tes gagal maka kode tersebut harus ditolak! Ini adalah satu-satunya cara untuk secara andal memelihara proyek perangkat lunak yang lebih besar.