Bagaimana cara membuat programmer junior menulis tes? [Tutup]

Kami memiliki programmer junior yang tidak cukup menulis tes.
Saya harus mengomelinya setiap dua jam, "apakah Anda sudah tes tertulis?"
Kami sudah mencoba:

• Menunjukkan bahwa desain menjadi lebih sederhana
• Menampilkannya mencegah cacat
• Menjadikannya sebagai hal ego yang mengatakan bahwa hanya programmer yang buruk tidak
• Akhir pekan ini 2 anggota tim harus datang untuk bekerja karena kodenya memiliki referensi NULL dan dia tidak mengujinya

Pekerjaan saya memerlukan kode stabil berkualitas tinggi, dan biasanya semua orang 'mendapatkannya' dan tidak perlu melakukan pengujian. Kami tahu kami bisa membuatnya menulis tes, tapi kami semua tahu tes yang berguna adalah tes tertulis saat Anda menyukainya.

Apakah Anda mengetahui lebih banyak motivasi?

Ini adalah salah satu hal tersulit untuk dilakukan. Membuat orang-orang Anda mendapatkannya .

Terkadang salah satu cara terbaik untuk membantu programmer tingkat junior 'mendapatkannya' dan mempelajari teknik yang tepat dari para senior adalah dengan melakukan sedikit pemrograman berpasangan.

Coba ini: pada proyek yang akan datang, pasangkan pria junior dengan diri Anda atau programmer senior lainnya. Mereka harus bekerja sama, bergiliran "mengemudi" (menjadi orang yang mengetik di keyboard mereka) dan "melatih" (melihat dari balik bahu pengemudi dan menunjukkan saran, kesalahan, dll saat mereka pergi). Ini mungkin tampak seperti pemborosan sumber daya, tetapi Anda akan menemukan:

1. Bahwa orang-orang ini bersama-sama dapat menghasilkan banyak kode dengan cepat dan berkualitas lebih tinggi.
2. Jika pria junior Anda cukup belajar untuk "mendapatkannya" dengan pria senior mengarahkannya ke jalan yang benar (mis., "Oke, sekarang sebelum kita melanjutkan, mari tulis di tes untuk fungsi ini.") Ini akan sepadan dengan sumber daya Anda berkomitmen untuk itu.

Mungkin juga ada seseorang di grup Anda yang memberikan presentasi Unit Testing 101 oleh Kate Rhodes, menurut saya ini cara yang bagus untuk membuat orang bersemangat tentang pengujian, jika disampaikan dengan baik.

Hal lain yang dapat Anda lakukan adalah meminta Pengembang Jr. Anda melatih Kata Game Bowling yang akan membantu mereka mempelajari Pengembangan Berbasis Tes. Ini ada di java, tapi bisa dengan mudah disesuaikan dengan bahasa apapun.

Minta peninjauan kode sebelum setiap komit (meskipun hanya 1 menit "Saya telah mengubah nama variabel ini"), dan sebagai bagian dari peninjauan kode, tinjau pengujian unit apa pun.

Jangan keluar dari komit sampai tes dilakukan.

(Juga - Jika karyanya tidak diuji - mengapa itu di tempat produksi di tempat pertama? Jika tidak diuji, jangan biarkan masuk, maka Anda tidak perlu bekerja di akhir pekan)

Untuk saya sendiri, saya sudah mulai bersikeras bahwa setiap bug yang saya temukan dan perbaiki diekspresikan sebagai tes:

1. "Hmmm, itu tidak benar ..."
2. Temukan kemungkinan masalah
3. Tulis tes, tunjukkan bahwa kode gagal
4. Perbaiki masalahnya
5. Tunjukkan bahwa kode baru berhasil
6. Ulangi jika masalah awal berlanjut

Saya mencoba melakukan ini bahkan saat membenturkan barang-barang, dan saya selesai dalam waktu yang hampir bersamaan, hanya dengan rangkaian pengujian parsial yang sudah ada.

(Saya tidak tinggal di lingkungan pemrograman komersial, dan seringkali saya satu-satunya pembuat kode yang mengerjakan proyek tertentu.)

Bayangkan saya adalah pemrogram tiruan, bernama ... Marco. Bayangkan saya telah lulus sekolah belum lama ini, dan tidak pernah benar-benar harus menulis tes. Bayangkan saya bekerja di perusahaan yang tidak benar-benar memaksakan atau meminta hal ini. BAIK? baik! Sekarang bayangkan, bahwa perusahaan beralih menggunakan tes, dan mereka mencoba membuat saya sejalan dengan ini. Saya akan memberikan reaksi yang agak tajam terhadap item yang disebutkan sejauh ini, seolah-olah saya tidak melakukan penelitian apa pun tentang hal ini.

Mari kita mulai dengan pembuatnya:

Menunjukkan bahwa desain menjadi lebih sederhana.

Bagaimana bisa menulis lebih banyak, membuat segalanya lebih sederhana. Sekarang saya harus mengawasi untuk mendapatkan lebih banyak kasus, dan lain-lain. Ini membuatnya lebih rumit jika Anda bertanya kepada saya. Beri saya detail yang solid.

Menampilkannya mencegah cacat.

Saya tahu itu. Inilah mengapa mereka disebut tes. Kode saya bagus, dan saya memeriksanya untuk masalah, jadi saya tidak melihat di mana tes itu akan membantu.

Menjadikannya sebagai hal ego yang mengatakan bahwa hanya programmer yang buruk tidak.

Ohh, jadi Anda mengira saya programmer yang buruk hanya karena saya tidak melakukan banyak pengujian bekas. Saya terhina dan secara positif kesal pada Anda. Saya lebih suka mendapat bantuan dan dukungan daripada ucapan.

@ Justin Standard : Pada awal pemasangan propect baru, pasangan junior dengan Anda sendiri atau programmer senior lainnya.

Ohh, ini sangat penting sehingga sumber daya akan digunakan untuk memastikan saya melihat bagaimana hal-hal dilakukan, dan meminta bantuan saya tentang bagaimana sesuatu dilakukan. Ini berguna, dan saya mungkin akan mulai lebih sering melakukannya.

@ Justin Standard : Baca presentasi Unit Testing 101 oleh Kate Rhodes.

Ahh, itu adalah presentasi yang menarik, dan itu membuatku berpikir tentang pengujian. Itu memantapkan beberapa poin yang harus saya pertimbangkan, dan itu mungkin sedikit mempengaruhi pandangan saya.

Saya ingin melihat artikel yang lebih menarik, dan alat lain untuk membantu saya agar sejalan dengan pemikiran bahwa ini adalah cara yang tepat untuk melakukan sesuatu.

@ Dominic Cooney : Luangkan waktu dan bagikan teknik pengujian.

Ahh, ini membantu saya memahami apa yang diharapkan dari saya dalam hal teknik, dan ini menempatkan lebih banyak item ke dalam kantong pengetahuan saya, yang mungkin saya gunakan lagi.

@ Dominic Cooney : Jawab pertanyaan, contoh, dan buku.

Memiliki titik orang (orang) untuk menjawab pertanyaan sangat membantu, itu mungkin membuat saya lebih cenderung untuk mencoba. Contoh yang baik itu bagus, dan memberi saya sesuatu untuk dibidik, dan sesuatu untuk dicari referensi. Buku-buku yang berhubungan langsung dengan ini adalah referensi yang bagus.

@ Adam Hayle : Ulasan Kejutan.

Katakan apa, Anda memunculkan sesuatu yang sama sekali tidak saya siapkan. Saya merasa tidak nyaman dengan ini, tetapi akan melakukan yang terbaik. Sekarang saya akan takut dan sedikit khawatir akan hal ini muncul lagi, terima kasih. Namun, taktik menakut-nakuti itu mungkin berhasil, tetapi ada biayanya. Namun, jika tidak ada yang berhasil, ini mungkin hanya dorongan yang diperlukan.

@ Rytmis : Item hanya dianggap selesai jika memiliki kasus uji.

Ohh, menarik. Saya melihat saya benar-benar harus melakukan ini sekarang, jika tidak, saya tidak menyelesaikan apa pun. Ini masuk akal.

@ jmorris : Singkirkan / Pengorbanan.

silau, silau, silau - Ada kesempatan saya bisa belajar, dan dengan dukungan, dan bantuan, saya bisa menjadi bagian yang sangat penting dan fungsional dari tim. Ini adalah salah satu kekurangan saya sekarang, tetapi tidak akan lama. Namun, jika saya tidak mengerti, saya mengerti bahwa saya akan pergi. Saya pikir saya akan mendapatkannya.

Pada akhirnya, dukungan dari tim saya berperan besar dalam semua ini. Membuat seseorang meluangkan waktu untuk membantu, dan membuat saya memulai kebiasaan baik selalu diterima. Kemudian, setelah itu memiliki jaring pendukung yang bagus akan sangat bagus. Akan selalu dihargai jika seseorang datang beberapa kali sesudahnya, dan memeriksa beberapa kode, untuk melihat bagaimana semuanya mengalir, bukan dalam ulasan saja, tetapi lebih sebagai kunjungan yang ramah.

Penalaran, Mempersiapkan, Mengajar, Tindak Lanjut, Dukungan.

Saya perhatikan bahwa banyak programmer melihat nilai pengujian pada tingkat yang rasional. Jika Anda pernah mendengar hal-hal seperti "ya, saya tahu saya harus menguji ini tetapi saya benar-benar harus menyelesaikan ini dengan cepat" maka Anda tahu apa yang saya maksud. Namun, pada tingkat emosional mereka merasa bahwa mereka menyelesaikan sesuatu hanya ketika mereka menulis kode yang sebenarnya.

Maka, tujuannya adalah untuk membuat mereka memahami bahwa pengujian sebenarnya adalah satu - satunya cara untuk mengukur kapan sesuatu "dilakukan", dan dengan demikian memberi mereka motivasi intrinsik untuk menulis tes.

Saya khawatir itu jauh lebih sulit dari yang seharusnya. Anda akan mendengar banyak alasan seperti "Saya benar-benar terburu-buru, saya akan menulis ulang / memfaktorkan ulang ini nanti dan kemudian menambahkan pengujian" - dan tentu saja, tindak lanjut tidak pernah terjadi karena, yang mengejutkan, mereka 'kembali seperti sibuk minggu depan .

Inilah yang akan saya lakukan:

• Pertama kali keluar ... "kami akan melakukan proyek ini bersama-sama. Saya akan menulis tes dan Anda akan menulis kodenya. Perhatikan cara saya menulis tes, karena begitulah cara kami melakukan sesuatu di sekitar sini dan itulah yang saya harapkan dari Anda. "

• Setelah itu ... "Kamu sudah selesai? Hebat! Pertama, mari kita lihat tes yang mendorong pengembangan Anda. Oh, tidak ada tes? Beri tahu saya jika sudah selesai dan kami akan menjadwalkan ulang untuk melihat kode Anda. Jika Anda ' membutuhkan bantuan untuk merumuskan tes beri tahu saya dan saya akan membantu Anda. "

Dia sudah melakukan ini. Betulkah. Dia hanya tidak menuliskannya. Tidak meyakinkan? Perhatikan dia melalui siklus pengembangan standar:

• Tulislah sebuah kode
• Kompilasi
• Jalankan untuk melihat apa yang dilakukannya
• Tulis kode berikutnya

Langkah # 3 adalah ujiannya. Dia sudah melakukan pengujian, dia hanya melakukannya secara manual. Ajukan pertanyaan ini kepadanya: "Bagaimana Anda tahu besok bahwa kode dari hari ini masih berfungsi?" Dia akan menjawab: "Jumlah kode yang sangat sedikit!"

Tanyakan: "Bagaimana dengan minggu depan?"

Ketika dia tidak mendapat jawaban, tanyakan: "Bagaimana Anda ingin program Anda memberi tahu Anda ketika perubahan merusak sesuatu yang berhasil kemarin?"

Itulah yang dimaksud dengan pengujian unit otomatis.

Sebagai programmer junior, saya masih mencoba membiasakan diri menulis tes. Jelas tidak mudah untuk mengambil kebiasaan baru, tetapi memikirkan tentang apa yang akan membuat ini berhasil untuk saya, saya harus memberi +1 pada komentar tentang ulasan kode dan pembinaan / pemograman pasangan.

Mungkin juga perlu ditekankan tujuan pengujian jangka panjang: memastikan bahwa apa yang berhasil kemarin masih berfungsi hari ini, dan minggu depan, dan bulan depan. Saya hanya mengatakan itu karena dalam membaca sekilas jawaban saya tidak melihat yang disebutkan.

Dalam melakukan tinjauan kode (jika Anda memutuskan untuk melakukan itu), pastikan pengembang muda Anda tahu ini bukan tentang menjatuhkannya, ini tentang membuat kode lebih baik. Karena dengan cara itu kepercayaan dirinya cenderung tidak rusak. Dan itu penting. Di sisi lain, begitu juga dengan mengetahui betapa sedikit yang Anda ketahui.

Tentu saja, saya tidak tahu apa-apa. Tapi saya harap kata-katanya bermanfaat.

Sunting: [ Justin Standard ]

Jangan merendahkan diri Anda sendiri, apa yang Anda katakan itu benar.

Pada poin Anda tentang ulasan kode: apa yang akan Anda temukan adalah bahwa pengembang junior tidak hanya akan belajar dalam prosesnya, tetapi juga para pengulas. Setiap orang dalam peninjauan kode belajar jika Anda menjadikannya sebagai proses kolaboratif.

Terus terang, jika Anda harus menempatkan bahwa banyak usaha dalam mendapatkan dia untuk melakukan sesuatu maka Anda mungkin harus datang untuk berdamai dengan pikiran bahwa ia hanya mungkin tidak cocok untuk tim, dan mungkin perlu untuk pergi. Sekarang, ini tidak berarti memecatnya ... itu mungkin berarti menemukan tempat lain di perusahaan yang keahliannya lebih cocok. Tetapi jika tidak ada tempat lain ... Anda tahu apa yang harus dilakukan.

Saya berasumsi bahwa dia juga karyawan baru (<1 tahun) dan mungkin baru saja keluar dari sekolah ... dalam hal ini dia mungkin tidak terbiasa dengan cara kerja berbagai hal di lingkungan perusahaan. Hal-hal seperti itu kebanyakan dari kita bisa lolos di perguruan tinggi.

Jika ini masalahnya, satu hal yang menurut saya berhasil adalah memiliki semacam "ulasan karyawan baru yang mengejutkan". Tidak masalah jika Anda belum pernah melakukannya sebelumnya ... dia tidak akan tahu itu. Dudukkan saja dia dan beri tahu dia bahwa Anda akan membahas penampilannya dan menunjukkan kepadanya beberapa angka nyata ... ambil lembar tinjauan normal Anda (Anda memiliki proses tinjauan formal, kan?) Dan ubah judulnya jika Anda mau sehingga terlihat resmi dan tunjukkan di mana dia berdiri. Jika Anda menunjukkan padanya dalam suasana yang sangat formal bahwa tidak melakukan tes berdampak buruk pada peringkat kinerjanya dibandingkan dengan hanya "mengomel" dia tentang hal itu, dia mudah-mudahan akan mengerti maksudnya. Anda harus menunjukkan kepadanya bahwa tindakannya akan benar-benar memengaruhinya, baik itu pembayarannya atau sebaliknya.

Saya tahu, Anda mungkin ingin menghindari melakukan ini karena ini tidak resmi ... tetapi saya pikir Anda memiliki alasan untuk melakukannya dan itu mungkin akan jauh lebih murah daripada harus memecatnya dan merekrut seseorang yang baru.

Sebagai programmer junior, saya pikir saya akan mengungkapkan seperti apa ketika saya menemukan diri saya dalam situasi yang sama dengan developer junior Anda.

Ketika saya pertama kali keluar dari universitas, saya menemukan bahwa itu sangat tidak melengkapi saya untuk menghadapi dunia nyata. Ya, saya tahu beberapa dasar JAWA dan beberapa filosofi (jangan tanya) tapi itu saja. Ketika saya pertama kali mendapatkan pekerjaan saya, itu sedikit menakutkan untuk sedikitnya. Biarkan saya memberi tahu Anda bahwa saya mungkin salah satu koboi terbesar di sekitar, saya akan meretas sedikit perbaikan bug / algoritma tanpa komentar / pengujian / dokumentasi dan mengirimkannya ke luar pintu.

Saya cukup beruntung berada di bawah pengawasan programmer senior yang baik hati dan sangat sabar. Beruntung bagi saya, dia memutuskan untuk duduk bersama saya dan menghabiskan 1-2 minggu memeriksa kode bersama saya yang sangat diretas. Dia akan menjelaskan di mana kesalahan saya, poin-poin penting dari c dan petunjuk (anak laki-laki melakukan itu membingungkan saya!). Kami berhasil menulis kelas / modul yang cukup baik dalam waktu sekitar satu minggu. Yang bisa saya katakan adalah jika pengembang senior tidak menginvestasikan waktu untuk membantu saya di jalur yang benar, saya mungkin tidak akan bertahan lama.

Untungnya, 2 tahun kemudian, saya berharap beberapa kolega saya mungkin menganggap saya programmer biasa.

Bawa pulang poin

1. Sebagian besar Universitas sangat buruk dalam mempersiapkan siswanya untuk menghadapi dunia nyata
2. Pemrograman berpasangan sangat membantu saya. Itu tidak berarti bahwa itu akan membantu semua orang tetapi itu berhasil untuk saya.

Tetapkan mereka ke proyek yang tidak memerlukan "kode stabil kualitas terbaik" jika itu urusan Anda dan biarkan jr. pengembang gagal. Mintalah mereka menjadi orang yang 'datang pada akhir pekan' untuk memperbaiki bug mereka. Banyak makan siang dan bicarakan tentang praktik pengembangan perangkat lunak (bukan ceramah, tetapi diskusi). Pada waktunya mereka akan memperoleh dan mengembangkan praktik terbaik untuk melakukan tugas yang diberikan kepada mereka.

Siapa tahu, mereka bahkan mungkin menemukan sesuatu yang lebih baik daripada teknik yang digunakan tim Anda saat ini.

Jika programmer junior, atau siapa pun, tidak melihat nilai dalam pengujian, maka akan sulit untuk membuat mereka melakukannya ... titik.

Saya akan membuat programmer junior mengorbankan akhir pekan mereka untuk memperbaiki bug. Tindakannya (atau kekurangannya) tidak mempengaruhinya secara langsung. Juga, tunjukkan bahwa dia tidak akan melihat kemajuan dan / atau kenaikan gaji jika dia tidak meningkatkan keahliannya dalam pengujian.

Pada akhirnya, bahkan dengan semua bantuan, dorongan, bimbingan, dia mungkin tidak cocok untuk tim Anda, jadi biarkan dia pergi dan mencari seseorang yang benar-benar mengerti.

Saya setuju dengan komentar RodeoClown tentang kode yang meninjau setiap komit. Begitu dia melakukannya beberapa kali dengan adil, dia akan terbiasa menguji berbagai hal.

Saya tidak tahu apakah Anda perlu memblokir komitmen seperti itu. Di tempat kerja saya, setiap orang bebas berkomitmen untuk semuanya, dan semua pesan komit SVN (dengan diff) diemail ke tim.

Catatan: Anda benar - benar menginginkan addon diffs berwarna thunderbird jika Anda berencana melakukan ini.

Atasan saya atau saya sendiri (2 pembuat kode 'senior') akan membaca komit, dan jika ada hal seperti "Anda lupa menambahkan pengujian unit" kami hanya menjentikkan email atau pergi dan mengobrol dengan orang tersebut, menjelaskan mengapa mereka tes unit yang dibutuhkan atau apapun. Semua orang didorong untuk membaca komit juga, karena ini cara yang bagus untuk melihat apa yang terjadi, tapi pengembang junior tidak banyak berkomentar.

Anda dapat membantu mendorong orang untuk membiasakan diri dengan hal ini secara berkala dengan mengatakan hal-hal seperti "Hai, bob, apakah Anda melihat komitmen yang saya lakukan pagi ini, saya menemukan trik bagus ini di mana Anda dapat melakukan bla bla apa pun, baca komitmen dan lihat bagaimana itu bekerja!"

NB: Kami memiliki 2 pengembang 'senior' dan 3 yang junior. Ini mungkin tidak berskala, atau Anda mungkin perlu menyesuaikan prosesnya sedikit dengan lebih banyak pengembang.

1. Jadikan cakupan kode sebagai bagian dari ulasan.
2. Jadikan "tulis tes yang mengekspos bug" sebagai prasyarat untuk memperbaiki bug.
3. Memerlukan tingkat cakupan tertentu sebelum kode dapat didaftarkan.
4. Temukan buku yang bagus tentang pengembangan yang digerakkan oleh pengujian dan gunakan untuk menunjukkan bagaimana pengujian pertama dapat mempercepat pengembangan.

Banyak sekali psikologi dan teknik-teknik "mentoring" yang bermanfaat, tetapi sejujurnya, ini hanya bermuara pada "tes tulis jika Anda ingin tetap memiliki pekerjaan, besok."

Anda dapat menyesuaikannya dengan istilah apa pun yang menurut Anda pantas, kasar atau lembut, tidak masalah. Tetapi faktanya adalah, programmer tidak dibayar untuk hanya mengumpulkan kode & memeriksanya - mereka dibayar untuk mengumpulkan kode dengan hati-hati, kemudian melakukan tes, kemudian menguji kode mereka, LALU periksa semuanya. (Setidaknya seperti itulah kedengarannya, dari uraian Anda.)

Oleh karena itu, jika seseorang akan menolak untuk melakukan pekerjaannya, jelaskan kepada mereka bahwa mereka dapat tinggal di rumah, besok, dan Anda akan mempekerjakan seseorang yang AKAN melakukan pekerjaan itu.

Sekali lagi, Anda dapat melakukan semua ini dengan lembut, jika menurut Anda itu perlu, tetapi banyak orang hanya membutuhkan tamparan keras dari Life In The Real World , dan Anda akan membantu mereka dengan memberikannya kepada mereka.

Semoga berhasil.

Ubah deskripsi pekerjaannya untuk sementara hanya menjadi tes menulis dan mempertahankan tes. Saya pernah mendengar bahwa banyak perusahaan melakukan ini untuk orang baru yang belum berpengalaman untuk sementara waktu ketika mereka mulai.

Selain itu, berikan tantangan saat dia dalam peran itu: Menulis tes yang akan a) gagal pada kode saat ini a) memenuhi persyaratan perangkat lunak. Mudah-mudahan itu akan membuatnya membuat beberapa tes yang solid dan menyeluruh (meningkatkan proyek) dan membuatnya lebih baik dalam menulis tes ketika dia mengintegrasikan kembali ke dalam pengembangan inti.

edit> memenuhi persyaratan perangkat lunak yang berarti bahwa dia tidak hanya menulis tes untuk dengan sengaja memecahkan kode ketika kode tidak pernah dimaksudkan atau diperlukan untuk mempertimbangkan kasus uji tersebut.

Jika kolega Anda kurang pengalaman menulis tes, mungkin dia mengalami kesulitan dalam menguji di luar situasi sederhana, dan itu memanifestasikan dirinya sebagai tes yang tidak memadai. Inilah yang akan saya coba:

• Luangkan waktu dan bagikan teknik pengujian, seperti injeksi ketergantungan, mencari casing edge, dan sebagainya dengan kolega Anda.
• Tawarkan untuk menjawab pertanyaan tentang pengujian.
• Lakukan review kode tes untuk sementara waktu. Minta kolega Anda untuk meninjau perubahan Anda yang merupakan contoh pengujian yang baik. Lihat komentar mereka untuk mengetahui apakah mereka benar-benar membaca dan memahami kode tes Anda.
• Jika ada buku yang sangat sesuai dengan filosofi pengujian tim Anda, berikan dia salinannya. Mungkin membantu jika umpan balik atau diskusi tinjauan kode Anda mereferensikan buku sehingga dia memiliki utas untuk diambil dan diikuti.

Saya tidak akan secara khusus menekankan faktor rasa malu / bersalah. Perlu diperhatikan bahwa pengujian diadopsi secara luas, praktik yang baik, dan menulis serta mempertahankan tes yang baik adalah kesopanan profesional sehingga rekan satu tim Anda tidak perlu menghabiskan akhir pekan mereka di tempat kerja, tetapi saya tidak akan mempermasalahkan poin-poin itu.

Jika Anda benar-benar perlu "menjadi tegar" maka buatlah sistem yang tidak memihak; tidak ada yang suka merasa dikucilkan. Misalnya, tim Anda mungkin memerlukan kode untuk mempertahankan tingkat cakupan pengujian tertentu (dapat dimainkan, tetapi setidaknya dapat diotomatiskan); membutuhkan kode baru untuk melakukan tes; mewajibkan peninjau untuk mempertimbangkan kualitas pengujian saat melakukan tinjauan kode; dan seterusnya. Melembagakan sistem itu harus berasal dari konsensus tim. Jika Anda memoderasi diskusi dengan hati-hati, Anda mungkin menemukan alasan mendasar lain pengujian kolega Anda tidak seperti yang Anda harapkan.

Merupakan tanggung jawab Mentornya untuk Mengajarnya. Seberapa baik Anda mengajar dia BAGAIMANA cara menguji. Apakah Anda memasangkan pemrograman dengannya? Junior kemungkinan besar tidak tahu BAGAIMANA mengatur tes yang baik untuk xyz.

Sebagai siswa baru SMP, dia tahu banyak Konsep. Beberapa teknik. Beberapa pengalaman. Tapi pada akhirnya, semua Junior adalah POTENSI. Hampir setiap fitur yang mereka kerjakan, pasti ada hal baru yang belum pernah mereka lakukan sebelumnya. Tentu saja Junior mungkin telah melakukan pola Negara yang sederhana untuk sebuah proyek di kelas, membuka dan menutup "pintu", tetapi tidak pernah melakukan penerapan pola di dunia nyata.

Dia hanya akan sebaik Anda mengajar. Jika mereka bisa "Dapatkan saja" menurut Anda apakah mereka akan mengambil posisi Junior di tempat pertama?

Menurut pengalaman saya, Junior dipekerjakan dan diberi tanggung jawab yang hampir sama dengan Senior, tetapi hanya dibayar lebih sedikit dan kemudian diabaikan ketika mereka mulai goyah. Maafkan saya jika saya tampak pahit, itu karena saya.

@ jomblo_gombal

Saya pernah memiliki pengembang senior dan "arsitek" mencaci saya dan penguji (ini adalah pekerjaan pertama saya setelah lulus kuliah) di email karena tidak terlambat dan menyelesaikan tugas yang "mudah" pada malam sebelumnya. Kami telah melakukannya sepanjang hari dan berhenti pada jam 7 malam, saya telah meronta-ronta sejak jam 11 pagi sebelum makan siang hari itu dan telah mengganggu setiap anggota tim kami untuk meminta bantuan setidaknya dua kali.

Saya menanggapi dan meng-cc tim dengan: "Saya telah kecewa pada Anda selama sebulan sekarang. Saya tidak pernah mendapatkan bantuan dari tim. Saya akan berada di kedai kopi di seberang jalan jika Anda membutuhkan saya. Saya maaf saya tidak bisa men-debug 12 parameter, 800 metode baris yang hampir semuanya bergantung pada. "

Setelah bersantai di kedai kopi selama satu jam, saya kembali ke kantor, mengambil omong kosong saya dan pergi. Setelah beberapa hari mereka menelepon saya menanyakan apakah saya akan datang, saya berkata saya akan datang tetapi saya ada wawancara, mungkin besok.

"Jadi, Anda berhenti?"

Di repositori sumber Anda: gunakan hook sebelum setiap komit (hook pra-komit untuk SVN misalnya)

Dalam hook itu, periksa keberadaan setidaknya satu kasus penggunaan untuk setiap metode. Gunakan konvensi untuk organisasi pengujian unit yang dapat dengan mudah Anda terapkan melalui hook pra-commit.

Pada server integrasi, kompilasi semuanya dan periksa cakupan pengujian secara teratur menggunakan alat cakupan pengujian. Jika cakupan pengujian tidak 100% untuk sebuah kode, blokir setiap komit dari pengembang. Dia harus mengirimkan kasus uji yang mencakup 100% kode.

Hanya pemeriksaan otomatis yang dapat menskalakan proyek dengan baik. Anda tidak dapat memeriksa semuanya dengan tangan.

Pengembang harus bermaksud memeriksa apakah kasus pengujiannya mencakup 100% kode. Dengan begitu, jika dia tidak melakukan 100% kode yang diuji, itu adalah kesalahannya sendiri, bukan kesalahan "Ups, maaf saya lupa".

Ingat: Orang tidak pernah melakukan apa yang Anda harapkan, mereka selalu melakukan apa yang Anda periksa.

Pertama, seperti yang ditunjukkan sebagian besar responden di sini, jika pria tersebut tidak melihat manfaatnya dalam pengujian, tidak banyak yang dapat Anda lakukan untuk mengatasinya, dan Anda telah menunjukkan bahwa Anda tidak dapat memecat pria tersebut. Namun, kegagalan bukanlah pilihan di sini, jadi bagaimana dengan beberapa hal yang dapat Anda lakukan?

Jika organisasi Anda cukup besar untuk memiliki lebih dari 6 pengembang, saya sangat menyarankan memiliki departemen Jaminan Kualitas (meskipun hanya satu orang untuk memulai). Idealnya, Anda harus memiliki rasio 1 penguji berbanding 3-5 pengembang. Hal tentang programmer adalah ... mereka adalah programmer, bukan penguji. Saya belum mewawancarai seorang programmer yang telah secara formal diajarkan teknik QA yang benar.

Sebagian besar organisasi membuat kesalahan fatal dengan menetapkan peran pengujian kepada karyawan baru, orang dengan jumlah eksposur SEDIKITNYA ke kode Anda - idealnya, pengembang senior harus dipindahkan ke peran QA karena mereka memiliki pengalaman dalam kode , dan (mudah-mudahan) telah mengembangkan indra keenam untuk bau kode dan titik kegagalan yang dapat muncul.

Selain itu, programmer yang membuat kesalahan mungkin tidak akan menemukan cacat karena biasanya bukan kesalahan sintaks (yang diambil dalam kompilasi), tetapi kesalahan logika - dan logika yang sama sedang bekerja ketika mereka menulis uji seperti ketika mereka menulis kode. Jangan biarkan orang yang mengembangkan kode menguji kode itu - mereka akan menemukan lebih sedikit bug daripada orang lain.

Dalam kasus Anda, jika Anda mampu membayar upaya kerja yang dialihkan, jadikan orang baru ini sebagai anggota pertama tim QA Anda. Buat dia membaca "Pengujian Perangkat Lunak di Dunia Nyata: Meningkatkan Proses", karena dia jelas membutuhkan beberapa pelatihan dalam peran barunya. Jika dia tidak menyukainya, dia akan berhenti dan masalah Anda masih terselesaikan.

Pendekatan yang sedikit kurang dendam adalah membiarkan orang ini melakukan apa yang mereka kuasai (Saya berasumsi orang ini dipekerjakan karena mereka sebenarnya kompeten di bagian pemrograman pekerjaan), dan menyewa satu atau dua penguji untuk melakukan pengujian ( Mahasiswa universitas sering memiliki praktikum atau istilah "co-op", akan menyukai eksposur, dan murah)

Catatan Samping: Akhirnya, Anda ingin tim QA melapor ke direktur QA, atau setidaknya tidak ke manajer pengembang perangkat lunak, karena memiliki laporan tim QA kepada manajer yang tujuan utamanya adalah menyelesaikan produk adalah konflik bunga.

Jika organisasi Anda lebih kecil dari 6, atau Anda tidak dapat membuat tim baru, saya sarankan pemrograman berpasangan (PP). Saya bukan pengonversi total dari semua teknik pemrograman ekstrem, tapi saya pasti percaya pada pemrograman berpasangan. Namun, kedua anggota tim pemrograman yang dipasangkan harus berdedikasi, atau tidak akan berhasil. Mereka harus mengikuti dua aturan: inspektur harus memahami sepenuhnya apa yang sedang dikodekan di layar atau dia harus meminta pembuat kode untuk menjelaskannya; pembuat kode hanya dapat membuat kode apa yang dapat dia jelaskan - tidak ada "Anda akan melihat" atau "percaya padaku" atau melambaikan tangan akan ditoleransi.

Saya hanya merekomendasikan PP jika tim Anda mampu melakukannya, karena, seperti pengujian, tidak ada sorakan atau ancaman yang akan membujuk beberapa introvert yang egois untuk bekerja sama jika mereka merasa tidak nyaman melakukannya. Namun, saya menemukan bahwa antara pilihan menulis spesifikasi fungsional terperinci dan melakukan tinjauan kode vs. pemrograman berpasangan, PP biasanya menang.

Jika PP bukan untuk Anda, maka TDD adalah taruhan terbaik Anda, tetapi hanya jika dipahami secara harfiah. Pengembangan yang Didorong Pengujian berarti Anda menulis pengujian terlebih dahulu, menjalankan pengujian untuk membuktikan bahwa pengujian tersebut benar-benar gagal, lalu tulis kode yang paling sederhana untuk membuatnya berfungsi. Imbalannya adalah sekarang Anda (harus) memiliki koleksi ribuan pengujian, yang juga merupakan kode, dan sama mungkinnya dengan kode produksi yang mengandung bug. Sejujurnya, saya bukan penggemar berat TDD, terutama karena alasan ini, tetapi berfungsi untuk banyak pengembang yang lebih suka menulis skrip pengujian daripada dokumen kasus uji - beberapa pengujian lebih baik daripada tidak sama sekali. Pasangkan TDD dengan PP untuk kemungkinan cakupan pengujian yang lebih baik dan lebih sedikit bug dalam skrip.

Jika semuanya gagal, minta pemrogram setara dengan toples sumpah - setiap kali programmer merusak build, mereka harus memasukkan $ 20, $ 50, $ 100 (apa pun yang cukup menyakitkan bagi staf Anda) ke dalam stoples yang menuju ke favorit Anda ( terdaftar!) amal. Sampai mereka membayar, hindari mereka :)

Semua bercanda, cara terbaik untuk membuat programmer Anda menulis tes adalah jangan biarkan dia memprogram. Jika Anda menginginkan seorang programmer, pekerjakan seorang programmer - Jika Anda ingin tes, sewa penguji. Saya mulai sebagai programmer junior 12 tahun yang lalu melakukan pengujian, dan itu berubah menjadi jalur karier saya, dan saya tidak akan menukarnya dengan apa pun. Departemen QA yang solid yang dipelihara dengan baik dan diberi kekuasaan serta mandat untuk meningkatkan perangkat lunak sama berharganya dengan pengembang yang menulis perangkat lunak tersebut.

Ini mungkin sedikit tidak berperasaan, tetapi cara Anda menggambarkan situasinya sepertinya Anda perlu memecat orang ini. Atau setidaknya jelaskan: menolak mengikuti praktik pengembangan rumah (termasuk tes menulis) dan memeriksa kode buggy yang harus dibersihkan orang lain pada akhirnya akan membuat Anda dipecat.

Alasan utama insinyur / pemrogram junior tidak meluangkan banyak waktu untuk merancang dan melakukan skrip pengujian, adalah karena sebagian besar sertifikasi Ilmu Komputer tidak terlalu membutuhkan ini, sehingga bidang teknik lainnya dibahas lebih lanjut dalam program perguruan tinggi, seperti pola desain.

Menurut pengalaman saya, cara terbaik untuk membiasakan para profesional junior adalah menjadikannya bagian dari proses secara eksplisit. Artinya, ketika memperkirakan waktu yang harus dilakukan iterasi, waktu merancang, menulis dan / atau mengeksekusi kasus harus dimasukkan ke dalam perkiraan waktu ini.

Terakhir, meninjau desain skrip pengujian harus menjadi bagian dari tinjauan desain, dan kode yang sebenarnya harus ditinjau dalam tinjauan kode. Hal ini membuat programmer bertanggung jawab untuk melakukan pengujian yang tepat dari setiap baris kode yang dia tulis, dan insinyur senior serta rekan kerja bertanggung jawab untuk memberikan umpan balik dan panduan tentang kode dan tes tertulis.

Berdasarkan komentar Anda, "Tunjukkan bahwa desain menjadi lebih sederhana" Saya anggap kalian berlatih TDD. Melakukan peninjauan kode setelah fakta tidak akan berhasil. Semua hal tentang TDD adalah bahwa ini adalah desain dan bukan filosofi pengujian. Jika dia tidak menulis tes sebagai bagian dari desain, Anda tidak akan mendapatkan banyak manfaat dari tes menulis setelah fakta - terutama dari pengembang junior. Dia akan kehilangan banyak kotak sudut dan kodenya akan tetap jelek.

Taruhan terbaik Anda adalah memiliki pengembang senior yang sangat sabar untuk duduk bersamanya dan melakukan beberapa pemrograman berpasangan. Dan terus lakukan itu sampai dia belajar. Atau tidak belajar, dalam hal ini Anda perlu menugaskannya kembali ke tugas yang lebih cocok untuknya karena Anda hanya akan membuat pengembang Anda yang sebenarnya frustrasi.

Tidak semua orang memiliki tingkat bakat dan / atau motivasi yang sama. Tim pengembang, bahkan yang gesit, terdiri dari orang-orang di "A-Team" dan orang-orang di "B-Team". Anggota A-Team adalah orang yang merancang solusi, menulis semua kode produksi non-sepele, dan berkomunikasi dengan pemilik bisnis - semua pekerjaan yang membutuhkan pemikiran di luar kotak. B-Team menangani hal-hal seperti manajemen konfigurasi, menulis skrip, memperbaiki bug yang lumpuh, dan melakukan pekerjaan pemeliharaan - semua pekerjaan yang memiliki prosedur ketat yang memiliki konsekuensi kecil untuk kegagalan.