Saya tidak memiliki makalah penelitian atau statistik untuk diberikan kepada Anda, tetapi saya akan menceritakan pengalaman saya bekerja di tim / organisasi yang secara historis memiliki cakupan tes unit rendah rata-rata dan tidak ada tes ujung ke ujung, dan secara bertahap memindahkan bilah ke tempat kita sekarang, dengan lebih banyak pendekatan ATDD (tetapi, ironisnya, bukan TDD tradisional).
Secara khusus, ini adalah bagaimana jadwal proyek digunakan untuk bermain (dan masih bermain di tim / produk lain dalam organisasi yang sama):
- Analisis dan implementasi hingga 4 minggu
- 2 minggu pengujian regresi, perbaikan bug, stabilisasi, dan rilis persiapan
- 1-2 minggu memperbaiki kerusakan yang diketahui
- 2-3 minggu pembersihan kode dan masalah / dukungan pasca produksi (cacat tidak diketahui / pemadaman yang tidak direncanakan)
Ini sepertinya overhead konyol, tetapi sebenarnya sangat umum, hanya sering ditutupi di banyak organisasi dengan QA yang hilang atau tidak efektif. Kami memiliki penguji yang baik dan budaya pengujian intensif, sehingga masalah ini ditangkap lebih awal, dan diperbaiki di muka (sebagian besar waktu), daripada diizinkan untuk bermain perlahan selama beberapa bulan / tahun. 55-65% overhead pemeliharaan lebih rendah daripada norma yang diterima secara umum yaitu 80% dari waktu yang dihabiskan untuk debugging - yang tampaknya masuk akal, karena kami memang memiliki beberapa unit test dan tim lintas fungsi (termasuk QA).
Selama rilis pertama dari produk terbaru tim kami, kami telah mulai melakukan retrofit tes penerimaan tetapi mereka tidak cukup untuk menghabisi dan kami masih harus bergantung pada banyak pengujian manual. Rilis ini agak kurang menyakitkan daripada yang lain, IMO sebagian karena tes penerimaan serampangan kami dan juga sebagian karena cakupan unit uji kami yang sangat tinggi relatif terhadap proyek lain. Namun, kami menghabiskan hampir 2 minggu untuk regresi / stabilisasi dan 2 minggu untuk masalah pasca produksi.
Sebaliknya, setiap rilis sejak rilis awal itu memiliki kriteria penerimaan awal dan tes penerimaan, dan iterasi kami saat ini terlihat seperti ini:
- 8 hari analisis dan implementasi
- 2 hari stabilisasi
- 0-2 hari gabungan dukungan pasca pembersihan dan pembersihan
Dengan kata lain, kami mengalami peningkatan dari 55-65% overhead pemeliharaan ke 20-30% overhead perawatan. Tim yang sama, produk yang sama, perbedaan utama adalah peningkatan progresif dan perampingan tes penerimaan kami.
Biaya pemeliharaannya adalah, per sprint, 3-5 hari untuk analis QA dan 1-2 hari untuk pengembang. Tim kami memiliki 4 pengembang dan 2 analis QA, jadi (tidak termasuk UX, manajemen proyek, dll.) Itu maksimal 7 hari kerja dari 60 hari, yang saya akan kumpulkan hingga 15% biaya overhead implementasi hanya untuk berada di sisi aman.
Kami menghabiskan 15% dari setiap periode rilis mengembangkan tes penerimaan otomatis, dan dalam prosesnya dapat memotong 70% dari setiap rilis melakukan tes regresi dan memperbaiki bug pra-produksi dan pasca-produksi.
Anda mungkin memperhatikan bahwa timeline kedua jauh lebih tepat dan juga jauh lebih pendek daripada yang pertama. Itu adalah sesuatu yang dimungkinkan oleh kriteria penerimaan di muka dan tes penerimaan, karena sangat menyederhanakan "definisi selesai" dan memungkinkan kita untuk jauh lebih percaya diri dalam stabilitas rilis. Tidak ada tim lain yang (sejauh ini) berhasil dengan jadwal rilis dua mingguan, kecuali mungkin ketika melakukan rilis pemeliharaan yang cukup sepele (hanya perbaikan bug, dll.).
Efek samping lain yang menarik adalah kami dapat menyesuaikan jadwal rilis kami dengan kebutuhan bisnis. Suatu kali, kami harus memperpanjangnya menjadi sekitar 3 minggu untuk bertepatan dengan rilis lain, dan dapat melakukannya sambil memberikan lebih banyak fungsi tetapi tanpa menghabiskan waktu ekstra untuk pengujian atau stabilisasi. Di waktu lain, kami harus mempersingkatnya menjadi sekitar 1½ minggu, karena liburan dan konflik sumber daya; kami harus mengambil lebih sedikit pekerjaan dev, tetapi, seperti yang diharapkan, mampu menghabiskan lebih sedikit waktu untuk pengujian dan stabilisasi tanpa memperkenalkan cacat baru.
Jadi menurut pengalaman saya, tes penerimaan, terutama ketika dilakukan sangat awal dalam proyek atau sprint, dan ketika dirawat dengan baik dengan kriteria penerimaan yang ditulis oleh Pemilik Produk, adalah salah satu investasi terbaik yang dapat Anda lakukan. Tidak seperti TDD tradisional, yang orang lain benar menunjukkan lebih berfokus pada menciptakan diuji kode dari bebas cacat kode - ATDD benar-benar cacat membantu menangkap banyak lebih cepat; itu setara organisasi dengan pasukan penguji yang melakukan tes regresi lengkap setiap hari, tetapi jauh lebih murah.
Akankah ATDD membantu Anda dalam proyek jangka panjang yang dilakukan dalam gaya RUP atau (ugh) Waterfall, proyek yang berlangsung 3 bulan atau lebih? Saya pikir juri masih memilih yang itu. Dalam pengalaman saya, risiko terbesar dan paling jelek dalam proyek-proyek jangka panjang adalah tenggat waktu yang tidak realistis dan persyaratan yang berubah. Tenggat waktu yang tidak realistis akan menyebabkan orang mengambil jalan pintas, termasuk menguji jalan pintas, dan perubahan signifikan terhadap persyaratan kemungkinan akan membatalkan sejumlah besar tes, mengharuskan mereka untuk ditulis ulang dan berpotensi menggembungkan overhead implementasi.
Saya cukup yakin bahwa ATDD memiliki hadiah fantastis untuk model Agile, atau untuk tim yang tidak resmi tangkas tetapi memiliki jadwal rilis yang sangat sering. Saya belum pernah mencobanya pada proyek jangka panjang, terutama karena saya belum pernah atau bahkan pernah mendengar ada organisasi yang mau mencobanya pada proyek semacam itu, jadi masukkan disclaimer standar di sini. YMMV dan semua itu.
PS Dalam kasus kami, tidak ada upaya ekstra yang diperlukan dari "pelanggan", tetapi kami memiliki Pemilik Produk penuh waktu dan berdedikasi yang benar-benar menulis kriteria penerimaan. Jika Anda berada dalam bisnis "consultingware", saya menduga mungkin akan jauh lebih sulit untuk membuat pengguna akhir menulis kriteria penerimaan yang bermanfaat. Seorang Pemilik Produk / Manajer Produk sepertinya adalah elemen yang sangat penting untuk melakukan ATDD dan walaupun saya dapat sekali lagi hanya berbicara dari pengalaman saya sendiri, saya belum pernah mendengar ATDD berhasil dipraktikkan tanpa seseorang untuk memenuhi peran itu.
