Tes penerimaan dilakukan terlebih dahulu ... bagaimana ini bisa dicapai?

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 ...

pertama, singkirkan pemisahan antara 'penguji' dan 'pengembang'. Semua orang menguji

kedua, dalam TDD, para pengembang mengkode tes sebelum mereka membuat kode fitur / cerita

Yang Anda jelaskan bukanlah TDD [mungkin Scrum; Scrum adalah metodologi manajemen proyek yang tidak tergantung pada metodologi pengembangan; Scrum tidak relevan dengan masalah Anda]

Skenario di mana pengujian otomatis tidak mungkin sangat jarang terjadi. Skenario di mana pengujian otomatis sulit, mahal, atau tidak nyaman jauh lebih umum - tetapi justru inilah skenario di mana pengujian otomatis paling dibutuhkan.

Dari deskripsi yang tidak jelas, saya menganggap perangkat lunak menggambar sesuatu di layar. Jika apa yang sedang diambil ditentukan oleh data, formula, atau langkah fungsional, maka setidaknya tulis tes otomatis yang menguji ke tingkat data / formula / langkah fungsional. Jika output layar bersifat deterministik (langkah-langkah yang sama menghasilkan output gambar yang sama setiap kali) kemudian uji secara manual satu kali, ambil tangkapan layar, dan biarkan pengujian selanjutnya membandingkan hasil dengan tangkapan layar yang diverifikasi. Jika output layar tidak ditentukan dan tidak diatur oleh data, formula, atau langkah-langkah fungsional, maka Anda berada di area langka di mana pengujian otomatis mungkin tidak mungkin dilakukan. Tapi saya meragukannya.

Saya menduga bahwa satu-satunya alasan pengujian belum terotomatisasi sejauh ini adalah karena para pengembang tidak peduli tentang hal itu . Di TDD, para pengembang melakukan pengujian, sehingga mereka merasakan sakitnya pengulangan membosankan pengujian proses 62 langkah yang sama seratus kali sampai semua bug hilang. Tidak ada yang akan mendapatkan solusi pengujian otomatis yang dikembangkan lebih cepat daripada membuat pengembang melakukan pengujian.

Tim saya menemukan bahwa TDD tidak memadai untuk merancang tes GUI. Semua kerangka kerja pengujian tingkat GUI otomatis yang kami gunakan kode yang diperlukan harus ditulis sebelum pengujian. Jadi kami beralih ke Bevenor Driven Development . Tentu, tes tidak otomatis, tetapi itu memberi kami cara untuk mengukur apakah UI "selesai" dari awal.

Kami menemukan ATDD untuk GUI sulit / mahal.

Kami biasanya melakukan front-end terlebih dahulu. Karena kita menulis aplikasi web biasanya dalam HTML / CSS / JS, dan kemudian kita mendapatkan sign-off pada tampilan, aliran, dll. Ini akhirnya akan diterjemahkan ke dalam templat dengan bagian yang sesuai diganti dengan bit dinamis.

Setelah mockup UI selesai, kami menulis tes yang meniru permintaan web. XPath digunakan untuk menegaskan data yang ada di tag HTML yang benar.

Kami menemukan gaya pengujian ini memberi kami nilai bagus untuk waktu yang kami habiskan. Kami masih menegaskan data tersebut dikembalikan, dan beberapa struktur umum tentang html. Karena kami sudah mengerjakan tampilan sebelumnya melalui tahap mockup, kami tidak khawatir untuk mencoba menegaskan penempatan piksel. Kami hanya melihat halaman saat kami mengembangkan keduanya sebagai bagian dari pengembangan dan juga pemeriksaan ganda.

Untuk GUI non-web dev saya mungkin akan mencoba menambahkan beberapa kait untuk membuat skrip front end. Saya mungkin juga akan mempermainkan UI terlebih dahulu, meskipun di atas kertas.

 > Acceptance tests done first…how can this be accomplished?

Saya lebih suka gaya pengembangan bdd-tdd seperti yang dijelaskan dalam artikel ini: Pengembangan Berbasis Perilaku dengan SpecFlow dan WatiN .

Contoh ini menggunakan .net untuk pengembangan dengan SpecFlow + NUnit + WaitN. Jika Anda mengembangkan dengan (j) ruby ​​/ java Anda dapat mencoba mentimun + junit + waitr

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.

Ini kurang lebih apa yang kami lakukan. Setiap fitur dikembangkan secara paralel dengan test case (skrip) dan tidak ada fitur 'selesai' sampai ketiga langkah dilakukan: pengembangan, test case dan pengujian. Semua kasus uji ditulis dari persyaratan oleh penguji dan diperiksa dengan pengembang, jadi kita semua memiliki pemahaman yang sama tentang masalah tersebut. Seperti saran 'setiap dua minggu' Anda, kecuali bahwa ketika pengembang mengerjakan fitur, penguji sedang mengerjakan kasus uji dan ketika penguji sedang menguji, pengembang sedang menyelidiki fitur berikutnya.

Saya pikir masalah terbesar yang Anda miliki adalah itu

Dia menguji bagian dari tim yang sebenarnya tertinggal di belakang kami dengan selisih yang cukup besar. [...] Jika kami menunggu mereka, kami tidak akan menyelesaikannya

Karena tim penguji sangat jauh di belakang saya benar-benar berpikir Anda harus menunggu mereka. Saya yakin ada sesuatu yang produktif yang dapat Anda lakukan - seperti mengembangkan beberapa fitur yang mudah untuk diuji tetapi membutuhkan banyak waktu untuk berkembang. Ini juga dapat membantu untuk mempertimbangkan waktu pengujian ketika merencanakan sprint, baik pengembang atau penguji tidak boleh terlalu banyak bekerja atau menganggur.

Penerimaan pengembangan yang digerakkan oleh tes (berbeda dari, tetapi saling melengkapi dengan pengembangan yang digerakkan oleh pengujian) adalah cara yang bagus untuk memastikan bahwa Anda memiliki persyaratan yang terpaku sebelum Anda mulai membuat kode.

Di tim saya, kami (pemilik produk, analis dan pengembang QA) duduk bersama dan menggunakan dua tes penerimaan penulisan FitNesse . Sesi ini biasanya didorong oleh QA tetapi kita semua berpartisipasi. Ini tidak akan langsung berjalan karena beberapa upaya pengembangan diperlukan untuk menambahkan perlengkapan (lem antara halaman wiki dan kode produksi). Tes-tes ini membentuk kriteria penerimaan untuk sebuah cerita . FitNesse dirancang untuk berinteraksi dengan lapisan di bawah UI.

Sebagai pengembang, kami kemudian berupaya agar tes penerimaan ini lulus. Kami menggunakan TDD untuk ini, tetapi TDD tidak boleh dikacaukan dengan ATDD.

Setelah halaman FitNesse berubah hijau, kita hampir selesai, kita masih memiliki beberapa pekerjaan yang harus dilakukan (pengujian eksplorasi, biasanya dipimpin oleh QA, dan sebagainya).

Mungkin menulis tes UI kode dapat membantu Anda. Jika Anda bekerja dengan Visual studio 2010 Anda dapat menggunakan add-in yang disebut "tes kode ui" untuk merekam dan mengkodekan skrip yang sangat spesifik untuk berinteraksi dengan UI aplikasi Anda. Merekam interaksi ke dalam skrip memperkenalkan tingkat abstraksi ekstra yang melindungi Anda dari perubahan kecil di UI. Namun memperkenalkan bentuk pengujian ini juga memperkenalkan beban untuk mempertahankan tes.