Inti dasar dari sebagian besar metode Agile adalah bahwa fitur tidak "selesai" sampai dikembangkan, diuji, dan dalam banyak kasus dirilis. Ini seharusnya terjadi dalam potongan waktu yang cepat seperti "Sprint" dalam proses Scrum.
Bagian umum Agile juga TDD, yang menyatakan bahwa pengujian dilakukan terlebih dahulu.
Tim saya bekerja pada program GUI yang melakukan banyak gambar khusus dan semacamnya. Untuk memberikan tes, tim pengujian harus dapat bekerja dengan sesuatu yang setidaknya mencoba melakukan hal-hal yang mereka coba uji. Kami tidak menemukan jalan keluar untuk masalah ini.
Saya dapat melihat dari mana mereka datang karena jika saya mencoba untuk menulis perangkat lunak yang menargetkan beberapa antarmuka yang pada dasarnya misterius, saya akan mengalami kesulitan. Meskipun kami memiliki perilaku yang ditentukan dengan cukup baik, proses interaksi yang tepat dengan berbagai elemen UI ketika datang ke otomatisasi tampaknya terlalu unik untuk fitur sehingga memungkinkan penguji untuk menulis skrip otomatis untuk menggerakkan sesuatu yang tidak ada. Bahkan jika kita bisa, banyak hal yang akhirnya muncul setelah hilang dari spesifikasinya.
Satu hal yang kami pertimbangkan lakukan adalah meminta penguji menulis "skrip" pengujian yang lebih mirip seperangkat langkah yang harus dilakukan, seperti yang dijelaskan dari perspektif use-case, sehingga mereka dapat "diotomatisasi" oleh manusia. Ini kemudian dapat dilakukan oleh pengembang (s) menulis fitur dan / atau diverifikasi oleh orang lain. Ketika para penguji kemudian mendapatkan kesempatan mereka mengotomatiskan "skrip" untuk tujuan regresi terutama. Ini tidak berakhir di tim.
Bagian pengujian tim sebenarnya tertinggal di belakang kami dengan selisih yang cukup besar. Ini adalah salah satu alasan mengapa waktu tambahan untuk mengembangkan "skrip" bagi manusia untuk melakukan tidak terjadi ... mereka berada di bawah krisis untuk mengimbangi kami pengembang. Jika kami menunggu mereka, kami tidak akan menyelesaikan apa pun. Ini bukan kesalahan mereka sebenarnya, mereka leher botol tetapi mereka melakukan apa yang seharusnya dan bekerja secepat mungkin. Proses itu sendiri tampaknya diatur terhadap mereka.
Sangat sering kita akhirnya harus kembali sebulan atau lebih dalam apa yang telah kita lakukan untuk memperbaiki bug yang akhirnya harus diperiksa oleh penguji. Itu kebenaran buruk yang ingin saya lakukan sesuatu.
Jadi, apa yang dilakukan tim lain untuk mengatasi kaskade gagal ini? Bagaimana kita bisa membuat penguji di depan kita dan bagaimana kita bisa membuatnya sehingga sebenarnya ada waktu bagi mereka untuk menulis tes untuk fitur yang kita lakukan dalam sprint tanpa membuat kita duduk dan memutar-mutar ibu jari kita sementara itu? Saat ini sedang berjalan, untuk mendapatkan fitur "selesai", menggunakan definisi lincah, akan memiliki pengembang bekerja selama 1 minggu, kemudian penguji bekerja minggu kedua, dan pengembang mudah-mudahan bisa memperbaiki semua bug yang mereka hasilkan dalam beberapa hari terakhir. Itu tidak akan terjadi, bahkan jika saya setuju itu adalah solusi yang masuk akal. Saya butuh ide yang lebih baik ...