46

Bagaimana Anda meyakinkan manajer Anda untuk membiarkan Anda menguji unit?

Dengan "menggunakan", maksud saya diizinkan untuk berkembang, check-in ke sumber kontrol dan mempertahankan tes unit dari waktu ke waktu, dll.

Keberatan manajemen yang umum adalah:

Pelanggan tidak membayar untuk unit test
Proyek tidak memberikan waktu untuk pengujian unit
Hutang teknis? Utang teknis apa?

Apakah Anda tahu keberatan lainnya? Apa jawabanmu?

Terima kasih sebelumnya!

— louisgab
sumber

6

Ada satu bab dalam artofunittesting.com tentang topik ini.

— StuperUser

6

Jangan gabungkan tes dan TDD, TOLONG ! Itu membuat orang berpikir bahwa mereka tidak perlu tes kecuali mereka melakukan TDD!

— P Shved

1

Orang-orang yang butuh diyakinkan jauh dari meyakinkan. Pertimbangkan skenario Anda sebagai penyebab yang hilang.

— Mark Canlas

@Pavel, pada awalnya saya pikir Anda menipu, tetapi Anda benar. Saya ingin memiliki "izin" untuk pengujian unit, titik. TDD adalah urusan saya sendiri.

— louisgab

6

mengapa Anda merasa perlu mendapatkan izin untuk memverifikasi kode Anda berfungsi seperti yang diharapkan?

— Jaap

25

Saya mengalami masalah ini baru-baru ini ketika seorang pelanggan bergabung dengan metodologi kami, tetapi manajemen yang lebih tinggi mengetahui bahwa pengembang menghabiskan waktu pengujian daripada mengembangkan dan khawatir tentang ini - setelah semua, mereka memiliki orang-orang QA untuk melakukan pengujian! Saya membuat blog tentang bagaimana saya menghadapinya di sini:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Untuk meringkas, saya membandingkan perkiraan jam kami dengan jam aktual untuk proyek dan kemudian membandingkan tingkat cacat kami terhadap tingkat cacat tim lain. Dalam kasus kami angka-angka ini dibandingkan dengan baik dan tidak ada lagi kekhawatiran.

Kesimpulan saya berdasarkan pengalaman ini adalah:

... cara terbaik untuk meyakinkan siapa pun bahwa pendekatan Anda untuk melakukan sesuatu itu praktis dan pragmatis, adalah melakukannya dan mengukurnya terhadap pendekatan lain. Orang tidak peduli dengan dogma, atau mengapa Anda berpikir sesuatu harus menjadi cara terbaik. Hanya dengan menunjukkan kepada orang-orang jumlahnya dan mengukur efektivitas pendekatan Anda, Anda dapat benar-benar menunjukkan bahwa praktik Anda efektif.

Pada proyek lain, kami telah bekerja bersama pengembang pelanggan yang tidak membuat tes unit atau melakukan TDD dan kami harus mempertahankan tes yang mereka hancurkan. Namun, menjadi sangat mudah untuk menjual pendekatan TDD kepada para pengembang pelanggan tersebut ketika Anda dapat memberi tahu mereka apa yang mereka rusak dalam kode sebelum mereka tahu!

Jadi dalam kasus Anda, saya akan melakukannya secara sembunyi-sembunyi jika perlu (mungkin ada area kecil kode yang dapat Anda mulai untuk menguji perubahan itu sering atau yang Anda bertanggung jawab atas), tetapi tetap melacak nomor Anda - apa upaya untuk membuat tes Anda? Berapa tingkat cacatnya? Bagaimana hal ini dibandingkan dengan anggota proyek / tim lainnya?

Menurut pendapat saya, tidak ada yang perlu meminta izin atau meminta maaf karena ingin melakukan pekerjaan mereka dengan benar dan setiap pengembang profesional harus mencoba menguji kode mereka dengan tes otomatis di mana pun itu mungkin dan praktis. Mudah-mudahan kedua hal ini dalam kasus Anda. Semoga berhasil!

— Paddyslacker
sumber

Terima kasih atas tanggapannya. Saya mencoba tautannya tetapi tampaknya rusak. Saya pikir saya akan senang membacanya jika tersedia.

— Joe J

Joe, maaf tentang deadlink. Saya memposting ulang ini di blog pribadi saya, jadi tautannya harusnya berfungsi sekarang.

— Paddyslacker

2

Ini adalah jawaban yang baik tetapi tidak semua orang dapat dengan mudah membandingkan apa yang mereka lakukan dengan proyek lain. Saya tidak ingat di mana saya membacanya, tetapi argumen paling meyakinkan untuk seorang pebisnis yang pernah saya lihat adalah membandingkan pengujian unit dengan pembukuan entri ganda. Naif, melakukan angka dua kali adalah buang-buang waktu. Tetapi siapa pun yang tahu apa-apa tentang akuntansi akan menganggap melakukan hanya satu sisi dari buku sebagai kelalaian tugas yang tidak dapat dimaafkan. Unit testing adalah pengembangan pembukuan analog ke entri ganda.

— JimmyJames

@ JimmyJames, saya setuju bahwa Anda tidak selalu dapat dibandingkan dengan proyek lain, dan saya setuju dengan analogi Anda tentang pembukuan entri ganda. Saya pikir jika Anda mulai menggunakan tes unit pada basis kode yang ada tanpa tes, Anda dapat membandingkan tingkat cacat basis kode dan metrik lainnya antara bagian yang dicakup oleh unit test dan kode yang terbuka, sehingga Anda memiliki beberapa data nyata untuk dicadangkan pendekatan Anda juga.

— Paddyslacker

@Paddyslacker Saya tidak setuju. Ini agak seperti ayam dan telur. Jika Anda memerlukan izin untuk mulai menulis tes unit, sulit untuk menggunakannya untuk menunjukkan bukti bahwa izin harus diberikan. Bukan salah satu atau. Perbandingan dengan data nyata adalah argumen yang jauh lebih kuat. Argumen alternatif ini lebih lemah tetapi lebih mudah untuk dipasang.

— JimmyJames

20

Tunjukkan Pengembalian Investasi (ROI)

Menulis tes otomatis memerlukan waktu. Sekali. Menjalankan tes otomatis membutuhkan waktu nol, karena Anda dapat melakukan sesuatu yang lain saat sedang berjalan.

Contoh: Fitur pengujian X secara manual membutuhkan waktu 30 menit. Menulis tes otomatis untuk itu akan memakan waktu 1 jam. Bahkan jika kita tidak memiliki bug, kita harus menguji fitur X sepuluh kali selama proyek karena lapisan dependen dan komponennya dimodifikasi. Jadi mengotomatiskan pengujian fitur X akan menghemat kita 4 jam selama umur proyek.

Pada kenyataannya, saat Anda memiliki bug, tes otomatis benar-benar terbayar - Pertama, mereka menemukan bug lebih awal dan murah, yang menghemat waktu dan rasa malu. Kedua, jika Anda memiliki bug yang sulit dan menjalani banyak siklus pembuatan kode untuk mengetahuinya, waktu yang dihabiskan untuk pengujian manual bertambah sangat cepat.

Bisnis mengerti menghemat waktu dan uang. Begitulah cara menjualnya.

— Steven A. Lowe
sumber

3

Juga begitu aplikasi dikerahkan dan seseorang meminta perubahan, akan lebih mudah untuk melihat apakah Anda merusak sesuatu dengan perubahan Anda.

— m4tt1mus

4

@mattimus: tentu saja - suite tes otomatis terbayar seperti anuitas; itu, pada kenyataannya, asuransi

— Steven A. Lowe

15

Jika Anda sudah mengkonfrontasi mereka, dan mereka tidak setuju dengan itu, tetapi Anda tidak merasa nyaman menulis kode tanpa mereka ... maka jangan tanya lagi. Cukup tulis dan jangan periksa.

Manajemen tidak akan menghitung baris kode, tetapi mereka akan melihat bahwa semua checkin Anda memiliki tingkat kelulusan yang lebih tinggi dari QA (atau pelanggan) dan mereka pada akhirnya akan bertanya mengapa ... maka Anda bisa seperti "BAM! TDD ! "

Anda tidak mengacaukan proyek, proses atau sumber ... jadi saya tidak melihat alasan negatif. Jujur, saya tidak melihat alasan mengapa ini berbeda waktu daripada menjalankan semua uji coba + input + hasil tes manual.

— Steven Evers
sumber

4

+1: Anda tetap harus menguji. Cukup tulis unit test daripada berdalih tentang bagaimana pengujian "harus" dilakukan.

— S.Lott

1

Hanya membuatnya secara lokal tidak berfungsi dengan baik di lingkungan tim dengan basis kode bersama, orang lain akan terus melanggar tes Anda dengan perubahan mereka.

— Alb

3

@Alb: Itulah harga yang Anda bayar ketika manajemen tidak ikut - lebih baik daripada tidak ada tes sekalipun.

— Steven Evers

3

Bravo. Setiap tes lebih baik daripada tidak ada tes. Jika tes rusak karena perubahan orang lain, itu adalah alasan yang bagus untuk bertanya mengapa API berubah tanpa pengumuman apa pun.

— S.Lott

"Manajemen tidak akan menghitung baris kode" itu sangat benar. Terima kasih atas jawabannya!

— louisgab

7

1) Pelanggan tidak membayar untuk unit test

Pelanggan (mengira mereka) membayar untuk solusi kerja. Tergantung pada kontrak memperbaiki cacat mungkin sebenarnya menguntungkan bagi perusahaan Anda. Jika ada kunci yang cukup. Jadi kembali untuk membayar solusi yang berfungsi. TDD harus membantu tujuan itu.

2) Proyek tidak memberikan waktu untuk TDD

TDD tidak membutuhkan waktu lebih lama. Itu harus mengurangi jumlah kode asing atau berlebihan dan memfokuskan basis kode pada apa yang membuat tes lulus. Semua tes yang lulus, tergantung pada kualitas pengujian dan kesesuaian, berarti kode tersebut selesai.

3) Hutang teknis? Utang teknis apa?

Saya mendapat kesan bahwa Anda mungkin berdebat untuk secara retrospektif menambahkan tes ke kode yang ada. Ini adalah penjualan mimpi buruk pada saat terbaik dan tidak membawa manfaat yang Anda harapkan. Namun, menambahkan tes saat Anda memperbaiki bug harus dapat diterima dan membantu dalam jangka panjang.

Saya tidak merekomendasikan untuk menulis tes seperti yang disarankan Snorfus. Secara teori, ini terdengar bagus, tetapi unit test dapat dan memang berubah seiring waktu. Ketika persyaratan berubah, fitur-fitur baru ditambahkan, tes unit perlu diperbarui. Jika Anda bekerja sebagai bagian dari tim, pengujian unit Anda akan menjadi usang saat orang lain menambahkan fitur / perbaikan.

Saya membahas poin-poin spesifik yang Anda sebutkan daripada meningkatkan yang baru karena ada peluang di sana untuk membuat kemajuan atau memahami mengapa itu diblokir.

— Ian
sumber

5

"Aku tidak merekomendasikan untuk menulis tes" - Aku sudah berada di posisi ini sebelumnya. Sulit untuk mempertahankan tes sendiri. Jika beban itu menjadi terlalu berat, turun saja tes. Setidaknya Anda memilikinya ketika Anda secara aktif bekerja di basis kode, yang seharusnya membantu dengan desain / perbaikan awal, jika tidak menangkap regresi. Saya telah menemukan nilai luar biasa dalam pengujian unit untuk tujuan desain, tetapi saya telah menemukan beberapa regresi ketika tes tidak dipertahankan pada level yang sama dengan kode.

— Steve Jackson

1

Siapa pun yang menambahkan fitur / perbaikan dan tidak memperbarui tes unit tidak mengerti konsep uji unit.

— Akira Yamamoto

Memang Akira, ini adalah salah satu masalah paling membingungkan yang mempengaruhi kelangsungan hidup TDD atau proses terkait. Perlu diingat saya ternyata menulis ini 7 tahun yang lalu, masih banyak yang relevan. Tes menulis (baik, obyektif, ringkas) sulit. Menulis tes untuk basis kode yang tidak ada sangat sulit. Membuat manajemen non-teknis melihat manfaatnya sulit (kecuali mereka membaca sebuah artikel tentang hal ini dalam kasus mana Anda akan "metrik" mati. Bahkan konsep apa itu unit itu sulit. Saya seorang klasik ide saya tentang sebuah unit tidak sama dengan Mockist (sebagai contoh dengan 30 karakter tersisa)

— Ian

4

Untuk setiap pelanggan yang menghadapi masalah produksi,

Tulis tes Unit dan kirim email ke manajer yang mengatakan bahwa Anda telah menambahkan tes Unit untuk menutupi skenario.
Dan katakan kepadanya bahwa masalah ini tidak akan terjadi lagi di produksi karena pengujian unit kami berjalan setiap malam dan kami akan mengetahui sebelum kode masuk ke produksi dengan menonton kegagalan pengujian unit ini.
Katakan padanya bahwa jika kita sudah memiliki tes Unit ini sebelum kode masuk ke produksi, masalah produksi ini tidak akan pernah terjadi.

Lakukan ini secara konsisten dan gigih dan segera dia akan diyakinkan. Manajer tidak suka pelanggan menghadapi masalah produksi dan dia akan membeli ide pengujian Unit. Semoga berhasil.

— java_mouse
sumber

Ini bagus :-)

— BVengerov

Bagaimana Anda meyakinkan manajemen untuk "berinvestasi" dalam pengujian unit?

Tunjukkan Pengembalian Investasi (ROI)