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


8

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

Jawaban:


7

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.


Saya berbicara khusus tentang tes penerimaan, bukan tes unit. Bagaimanapun, saya tidak akan memiliki kesempatan untuk mengubah struktur departemen perusahaan. Perlu solusi yang berfungsi baik dengan pengembang dan "pengembang dalam pengujian". Yang mengatakan, bagaimana Anda melakukan contoh tangkapan layar Anda sebelum ada sesuatu untuk tangkapan layar? Sebenarnya ada BANYAK tes otomatis kami yang melakukan ini, tetapi sebelum hal seperti itu dapat diotomatisasi harus ada sesuatu untuk diambil tangkapan layarnya.
Edward Strange

@Crazy Eddie: TDD mendefinisikan tes untuk cerita pengguna yang menentukan fitur aplikasi. Terminologi 'unit test' sering digunakan dalam konteks ini, tetapi tidak memiliki arti terbatas yang sama dengan metodologi pengujian unit murni (misalnya cakupan kode, misalnya). TDD menguji fitur , dan meningkatkan hingga tingkat pengujian penerimaan. Penggunaan istilah 'unit testing' dalam literatur adalah titik kebingungan yang disesalkan bagi banyak orang. Adapun tangkapan layar, Anda harus menjalankannya dengan sukses sekali sehingga pendekatan itu hanya baik untuk pengujian regresi.
Steven A. Lowe

@Crazy Eddie: dengan nama seperti Crazy Eddie, saya berharap Anda menjadi juara dari siklus kegagalan yang tidak efisien dan sia-sia ;-) [ya saya baca blog Anda]. Serius, tidak ada yang akan berubah karena pengembang tidak merasakan sakit. Biarkan mereka merasakan sakitnya - atau mungkin menawarkan mereka semacam imbalan karena membantu - dan mereka akan menemukan solusi untuk pengujian otomatis, dan / atau mulai menulis kode yang lebih mudah untuk diuji.
Steven A. Lowe

Perbedaan yang saya anggap paling penting dari sudut pandang saya adalah bahwa mereka membutuhkan bidang keahlian yang berbeda. Tes unit dapat, dan sering kali, ditulis dalam bahasa yang sama dengan bit aplikasi yang mereka uji. Pengujian penerimaan otomatis di sisi lain menggunakan bahasa apa pun yang digunakan perangkat lunak tertentu untuk mendorong UI merespons. Mereka memerlukan arsitektur yang berbeda juga, karena setidaknya penguji kami telah mengembangkan perpustakaan besar komponen yang dapat digunakan kembali yang mereka beradaptasi untuk kebutuhan spesifik. Sama seperti sebuah tim yang dapat melibatkan pakar DB vs kode, tampaknya baik untuk memiliki pakar pengujian.
Edward Strange

Saya kira ini memecahkan masalah membuat pengembang sibuk sementara tes dilakukan. Bahkan jika itu membutuhkan waktu lebih lama untuk tugas yang diberikan, itu bisa bermanfaat. Saya mungkin tidak mendapatkan pembelian yang saya butuhkan dan saya membayangkan masalahnya tetap muncul kembali sampai kita dapat mengetahui bagaimana cara mendapatkan tes yang ditulis sebelumnya atau setidaknya dalam sinkronisasi. Saya masih tidak melihat cara untuk menyelesaikan masalah ini karena persyaratan memiliki sesuatu untuk dikendarai tampaknya menjadi prasyarat masalah otomasi.
Edward Strange

4

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.


3

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.


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


1

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.


1

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


Saya melihat bagaimana tes unit dan tes penerimaan tidak perlu bingung. Bukan berarti Paman Bob adalah dewa, tetapi dalam "Prinsip Agile, Pola dan Praktek di C #" ia memasukkan pengujian penerimaan (dan menggunakan FitNesse) sebagai bagian dari TDD dan tidak membuat perbedaan dan bahkan tidak menyebut ATDD.
JeffO

0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.