Tinjauan kode tertinggal di belakang Siklus Kirim / Uji

Dalam proses Agile kami, kami memiliki Sprint 2 minggu. Tugas dikirimkan setiap hari (harian dibangun), dan Tim Uji menyelesaikan pengujian mereka segera pada hari berikutnya atau bahkan pada hari yang sama.

Kami juga memiliki ulasan kode Dev, yang memerlukan waktu (1-2 jam), sehingga dijadwalkan 3 kali seminggu: Senin-Jumat-Jumat. Pengembang berkumpul dan menyarankan cara meningkatkan / memperbaiki kode.

Masalah kita adalah, pada saat Item Aksi muncul setelah peninjauan kode, sebagian besar tugas sudah diuji. Penguji tidak ingin menguji ulang apa yang sudah lulus tes mereka. Mereka tidak peduli dengan perubahan internal dev.

Apakah kita salah memahami proses Agile? Apakah ulasan kode tidak sesuai dengan siklus Rilis / Uji harian? Kami tidak dapat menahan ulasan kode setiap hari, karena ini menyita waktu semua orang.

Penguji tidak ingin menguji ulang adalah seperti mengatakan "coders tidak ingin melakukan refactor." Itu bagian dari pekerjaan. Prosesnya dapat dinyatakan kembali seperti ini: Tugas dibuat. Kode dihasilkan. Kode diuji. Kode ditinjau. Ketidaksempurnaan ditemukan dalam kode. Tugas Baru dibuat untuk mengatasi ketidaksempurnaan ini (mis. Kode direactored). Tugas-tugas baru ini membutuhkan pengujian baru.

Jika Anda akan meninjau kode di beberapa titik, itu tidak lebih mahal untuk melakukan tinjauan awal. Dan sepertinya Anda memiliki proses pengujian yang mahal, jadi Anda tidak ingin menguji dua kali. Oleh karena itu lebih murah untuk meninjau kode sebelum pengujian. Meninjau kode setelah pengujian tidak membuat pekerjaan berjalan lebih cepat. Itu membuatnya lebih lambat dan menggoda Anda untuk memberikan kode yang ditulis dengan buruk tetapi berhasil diuji. Seiring waktu semua kode yang tidak ditinjau ini akan membuat pekerjaan semakin lambat. Kemudian pesaing yang lebih efisien memberikan produk yang lebih baik dengan biaya lebih murah dan permainan berakhir.

Juga, mengotomatiskan pengujian. Pengujian manual begitu tahun 1970.

Jika Anda merasa sulit untuk mendapatkan ulasan kode terjadi pada waktu yang Anda miliki sebelum QA, Anda harus mempertimbangkan membuat ulasan kode lebih ringan, seperti Tinjauan Kode di Tim Agile, Bagian II yang diposting oleh @Dukeling diposting.

Saya menemukan bahwa bahkan hal paling sederhana yang dapat disebut tinjauan kode memberi manfaat: sebelum melakukan kode (atau mendorong dalam DVCS), hubungi satu pengembang lain dan bawa mereka melalui perubahan Anda. Ini mungkin memakan waktu lima atau sepuluh menit. Tujuan dari tinjauan kode ini adalah "Apakah ini masuk akal bagi pengembang lain?" Tujuannya bukan untuk memanfaatkan implementasi desain atau untuk sepenuhnya menyesuaikan diri dengan ide-ide pribadi pengamat tentang bagaimana seharusnya itu ditulis. Ini memberi manfaat ini:

• Peningkatan pengetahuan bersama tentang cara kerja kode
• Tertangkap kode membingungkan atau berpotensi salah karena tindakan menjelaskan kode sudah cukup untuk membuat penulis memikirkan kembali hal-hal
• Berangsur-angsur membantu mengembangkan idiom dan gaya tim, karena memudahkan menjelaskan hal-hal
• Sangat sedikit menggerutu dari tim

Ulasan kode yang lebih dalam benar-benar berfungsi lebih baik untuk menemukan masalah. Tetapi Anda harus dapat melakukannya dan menindakinya untuk mendapatkan nilai. Proses ringan yang dapat Anda lakukan sepanjang waktu bisa lebih membantu daripada proses kelas berat yang terus ditunda, atau hanya menambahkan hal-hal ke dalam tumpukan.

Salah satu solusi untuk masalah ini adalah dengan melakukan tinjauan cepat kode oleh rekan lain setelah cerita pengguna selesai, sehingga tidak akan ada kesalahan mendasar / jelas dalam kode.

Tetapi ini harus terjadi sebelum siklus tes. Maka akan ada lebih sedikit perubahan kode setelah tes, ketika Anda melakukan review yang lebih besar dengan semua tim bersama.

Dari bunyi itu penguji tidak ingin menguji ulang karena pengujian adalah proses yang menyakitkan / mahal.

Otomatisasi uji baik oleh devs dan penguji adalah bonus besar untuk tim yang berusaha bekerja dengan gesit. Semakin murah, mudah, dan semakin dapat direproduksi tes Anda maka semakin banyak Anda dapat menjalankannya - dan semakin sedikit resistensi yang Anda dapatkan untuk mengubah sesuatu.

Dilakukan refactor cepat berdasarkan beberapa umpan balik dev? Tekan tombol merah besar yang menjalankan suite regresi / asap Anda dan lakukan manual cepat sekali lagi untuk memeriksa masalah visual yang mungkin muncul. Mudah!

Setelah Anda berada di tempat seperti itu, pengujian ulang tidak akan menjadi tugas - itu akan menjadi kebiasaan.