pengembangan berbasis tes - Siapa yang harus menulis tes?

Awalnya, itu adalah tugas pengembang untuk menulis tes, tetapi saya perhatikan bahwa dalam banyak kasus / pengembang e-mature kasus-kasus itu tidak memberikan cakupan bahkan 80%.
Bagaimana kalau saya memiliki orang QA yang didedikasikan untuk menulis SEMUA tes untuk proyek yang diberikan, bukan pengembang?
Apakah ada kontra untuk itu?

Dalam Pengembangan Test-Driven, tes harus ditulis oleh pengembang. Kalau tidak, orang lain selain pengembang yang mendorong pengembangan.

Jadi, begitu Anda memberikan pekerjaan menulis tes kepada non-pengembang, orang itu menjadi pengembang.

Pengalaman saya dalam TDD adalah bahwa menulis kode pengujian seringkali sama sulit atau sulit daripada menulis kode produksi. Jadi, jika Anda memiliki sumber daya yang mampu menulis tes unit bagus / kode uji integrasi, mereka harus menulis kode produksi yang membuat tes tersebut lulus.

Tugas QA adalah melakukan jenis pengujian yang sepenuhnya berbeda (yaitu pengujian kegunaan / integrasi). Mereka tidak benar-benar harus tahu teknologi yang digunakan dalam kode.

Jika Anda khawatir tentang cakupan kode rendah, Anda perlu mendisiplinkan pengembang Anda. Misalnya menghentikan pekerjaan pada fitur baru, hingga jangkauan kode meningkat. Beberapa organisasi sejauh memiliki kait pra-komit di repositori mereka yang tidak akan mengizinkan check-in membuka kode.

Terakhir tetapi tidak kalah pentingnya, dalam TTD 'murni', seharusnya tidak ada kode terbuka sama sekali (karena Anda menulis tes terlebih dahulu). Namun ada beberapa kasus (meskipun orang-orang memperdebatkannya) di mana cakupan kode yang lebih rendah dapat diterima. Beberapa berpendapat misalnya, bahwa tes menulis untuk pengambil / set POJO adalah buang-buang waktu.

kasus-kasus itu bahkan tidak memberikan cakupan 80%

Itu bisa menjadi masalah manajemen.

Atau bisa jadi tidak relevan.

Pertama, perbedaan antara cakupan 80% dan 100% mungkin banyak biaya untuk manfaat yang sangat sedikit.

"Cakupan" bisa berarti apa saja. Garis-garis kode, jalur logika, dll. Saya kira maksud Anda adalah baris kode (bukan jalur logika).

Beberapa jalur logika diuji dengan cukup baik "dengan inspeksi". Kode ini jelas, tidak memiliki pernyataan if, memiliki kompleksitas yang sangat, sangat rendah, dan mungkin tidak memerlukan tes tambahan.

20% lebih banyak tes tidak selalu berkualitas 20% lebih tinggi.

Kedua. Ini masalah manajemen. Jika manajemen menginginkan cakupan 100%, mereka harus menerapkan sistem penghargaan yang memberi imbalan pada cakupan 100% alih-alih "cukup baik untuk melepaskan" cakupan 80%.

Menambahkan QA orang untuk menulis lebih banyak tes tidak akan banyak membantu.

Menambahkan pengembang untuk menulis lebih banyak tes adalah apa yang diperlukan untuk mendapatkan cakupan pengujian 100%.

Unit testing IMHO bukan proses QA. Ini lebih lanjut tentang mempercepat pengembangan (dengan mengecilkan loop umpan balik untuk pengembang). Itu harus dilakukan oleh orang yang menulis komponen (alias unit) dengan fokus pada penggunaan komponen (oleh pengembang lain).

Pengujian fungsional adalah proses QA yang dapat dan harus dilakukan oleh tim QA. Ini dapat dilakukan oleh pengembang tetapi yang bukan pengembang akan lebih baik karena pengembang mungkin tidak tahu semua cara pengguna mungkin menggunakan aplikasi.

Keduanya dapat dilakukan secara TDD.

TDD tidak hanya tentang pengujian, tetapi juga tentang desain. Menulis kode hanya untuk lulus tes biasanya mengarah ke kode yang lebih kecil dan dapat dipelihara. Jika Anda mendelegasikan orang lain untuk menulis tes, Anda juga akan mendelegasikan tanggung jawab membuat kode yang baik.

Anda juga harus mencatat bahwa jangkauan tidak akan memberi tahu Anda tentang kualitas kode dan tidak akan memberi tahu Anda jika aturan domain sedang dicakup.

Jika Anda membutuhkan setidaknya 80% perlindungan, maka Anda perlu melakukan beberapa hal:

• Berikan pengembang Anda alat yang mereka butuhkan untuk menentukan tingkat cakupan yang mereka miliki - dan pastikan itu adalah apel untuk apel. Ada lebih dari satu cara untuk mengukur cakupan.
• Berikan hadiah / insentif untuk mencapai prestasi itu. Programmer hanya akan melakukan apa yang mereka rasa akan berhasil. Jika cakupan 50% cukup baik untuk memastikan kualitas dan menyelesaikan semua pekerjaan, itulah yang akan mereka lakukan.

Akhirnya, memahami bahwa ada perbedaan antara dimaksudkan jalur eksekusi dan tidak diinginkan jalur eksekusi. Dalam proses penulisan kode yang digerakkan tes, Anda mungkin telah membuktikan bahwa Anda memerlukan sepasang pernyataan independen. Akibatnya ada tes untuk dua dari empat jalur eksekusi yang tersedia. Tambahkan satu lagi jika pernyataan independen, dan Anda memiliki potensi untuk delapan jalur eksekusi (yaitu naik secara eksponensial).

Memahami bahwa TDD tidak selalu memprediksi setiap jalur eksekusi potensial, jadi ada sejumlah tes yang mungkin perlu ditulis agar lengkap tetapi tidak ditulis karena tidak perlu menguji jalur itu. Singkatnya, TDD tidak menjamin cakupan, tetapi menjamin bahwa setidaknya ada satu tes untuk membuktikan alasan d'eter untuk kode yang ada.