Apakah BDD sebenarnya dapat ditulis oleh non-programmer?


24

Pengembangan Behavior-Driven dengan simbol skenario "Given-When-Then" simbolik akhir-akhir ini cukup populer karena kemungkinan penggunaannya sebagai objek batas untuk penilaian fungsionalitas perangkat lunak.

Saya pasti setuju bahwa Gherkin , atau skrip definisi fitur mana pun yang Anda inginkan, adalah DSL yang dapat dibaca oleh bisnis , dan sudah memberikan nilai seperti itu.

Namun, saya tidak setuju bahwa ini dapat ditulis oleh non-programmer (seperti halnya Martin Fowler ).

Adakah yang memiliki akun skenario yang ditulis oleh non-programmer, kemudian diinstrumentasi oleh pengembang?

Jika memang ada konsensus tentang kurangnya kemampuan menulis, apakah Anda akan melihat masalah dengan alat yang, alih-alih memulai dengan skenario dan menginstruksikannya, akan menghasilkan skenario yang dapat dibaca bisnis dari tes yang sebenarnya?

Pembaruan: mengenai alat "generator skenario", tentu saja tidak akan menebak bahasa bisnis secara ajaib;) Tapi, sama seperti saat ini kami menggunakan pencocokan regexp untuk membuat tes dalam pendekatan top-down (pada dimensi abstraksi), kita dapat menggunakan pembangun string untuk membuat skenario dalam pendekatan bottom-up.

Contoh "untuk memberikan ide saja":

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Akan lama sebelum manusia dapat datang dengan bahasa umum yang dapat dibaca oleh manusia lain dengan cara yang tepat, bahkan setelah komputer sudah dapat menulis kode untuk komputer.

Ironisnya, JBehave 1 (alat BDD pertama) dimulai dengan membuat skenario yang dapat dibaca bisnis. Kami tidak menguraikan bahasa Inggris sampai Mentimun. Saya pikir JBehave 1 berguna untuk benar-benar mengingatkan orang bahwa mereka harus berbicara tentang mereka terlebih dahulu ...
Lunivore

Jawaban:


20

Saya pernah melihatnya. Tidak berakhir dengan baik.

Saya pikir mentimun adalah abstraksi yang rumit (<- lol: D) untuk alasan yang tepat ini. Terlalu sulit bagi orang non-teknis untuk menulis sendiri; terlalu bertele-tele untuk orang-orang teknis.

Orang-orang non-teknis belum belajar berpikir seperti programmer. Merupakan hak istimewa kami untuk memahami pengetahuan abstrak, memecahnya, membangun kembali dan masih dapat melarikan diri dari ambiguitas dengan sukses. Untuk itulah kita dibayar.

Jika memang ada konsensus tentang kurangnya kemampuan menulis, apakah Anda akan melihat masalah dengan alat yang, alih-alih memulai dengan skenario dan menginstruksikannya, akan menghasilkan skenario yang dapat dibaca bisnis dari tes yang sebenarnya?

Alat itu sendiri tidak akan dapat menghasilkan mereka. Komputer tidak tahu apa-apa tentang domain bisnis. Pada akhirnya - programmer akan bertanggung jawab untuk menggambar apa yang perlu dihasilkan dan bahkan kemudian - kemungkinan skenario itu akan terlalu bertele-tele / samar untuk pengguna akhir mereka.


20
Non technical people just haven't learned to think like programmers. Kebenaran. Konsep yang sama ini telah digembar-gemborkan dan diciptakan kembali beberapa kali dalam 20 tahun terakhir dan hampir selalu berakhir dengan hasil yang buruk. Bisnis menyukai konsep mendapatkan perangkat lunak tanpa harus membayar para pengembang perangkat lunak lintah yang menghisap darah rakus tetapi mereka lupa bahwa bagian tersulit dari pengembangan perangkat lunak adalah sebagian besar waktu memahami aturan bisnis lebih dalam dan lebih rumit daripada orang-orang bisnis itu sendiri.
maple_shaft

2
"Orang-orang non-teknis belum belajar berpikir seperti programmer." Ya, kemampuan untuk menguraikan masalah dan mengekspresikannya dalam istilah logika atom tertentu mungkin adalah apa yang membuat seseorang menjadi programmer / analis. Gagasan bahwa terlihat seperti bahasa Inggris membuat Gherkin dapat digunakan oleh siapa pun tampaknya sangat naif bagi saya. Terima kasih telah mengkonfirmasi :) Computer knows nothing about business domain.Tentu saja. Saya tidak memperjelas ide saya, maaf soal itu. Saya akan menambahkan info ke pertanyaan.
MattiSG

8
@maple_shaft: 20 tahun terakhir? Coba 60 tahun terakhir. Beberapa hype awal sekitar COBOL adalah bahwa para pebisnis bisa menulisnya, menghilangkan kebutuhan untuk programmer. Ketika itu gagal terjadi, orang-orang datang dengan sekelompok apa yang mereka sebut bahasa generasi keempat yang seharusnya melakukan hal yang sama.
David Thornley

11

Bagian dari kesulitan dalam hal pelanggan menulis dokumen spesifikasi adalah bahwa pelanggan sering tidak tahu bagaimana menerjemahkan hal-hal yang diinginkan pelanggan ke dalam bahasa yang sebenarnya menggambarkan apa yang dibutuhkan pelanggan. Sementara pelanggan mungkin mengatakan bahwa mereka ingin perilaku tertentu ada dalam suatu sistem, mereka umumnya tidak begitu peduli dengan hal-hal kecil sampai mereka telah melihat dan menggunakan dan mengalami perangkat lunak yang bekerja dengan cara yang menurut pelanggan tidak cukup cocok dengan mereka. kebutuhan.

Ketika pelanggan menggambarkan suatu proses bisnis, mereka sering meninggalkan banyak informasi yang relevan. Seringkali informasi ini berkaitan dengan hal-hal tentang suatu proses yang biasanya dipahami dalam domain khusus pelanggan dan oleh karena itu diterima begitu saja dan seringkali tidak disampaikan ke programmer. Di lain waktu, pelanggan tidak benar-benar tahu bagaimana menghadapi semua kondisi batas dalam suatu sistem, dan mencari programmer untuk bimbingan. Kadang-kadang itu semua adalah kasus sederhana dari kegunaan, dengan pelanggan berpikir mereka ingin sesuatu bekerja dalam satu cara, tetapi kemudian berubah pikiran ketika menjadi lebih jelas bahwa segala sesuatu harus bekerja secara berbeda.

Oke, cukup "relasi pelanggan untuk programmer". Pertanyaannya adalah apakah masih ada nilai dalam membuat pelanggan menggunakan DSL yang dapat dibaca bisnis untuk menentukan cara mendefinisikan spesifikasi. Saya percaya bahwa dengan panduan, jawabannya adalah tentatif 'ya', dan saya katakan tentatif karena pertanyaan berikutnya yang muncul dalam pikiran adalah, mengapa Anda memiliki pelanggan yang membuat DSL ketika Anda dapat memiliki programmer lebih mudah menentukan yang akan menyediakan pelanggan dengan bahasa yang sederhana namun kaya untuk menentukan bagaimana sistem perlu bekerja?

Ketika Anda telah menyediakan pelanggan dengan bahasa untuk menggambarkan bagaimana mereka ingin sistem untuk bekerja, Anda akan berakhir dengan pernyataan yang mengatakan sesuatu seperti:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Jenis pernyataan ini pada akhirnya menggambarkan suatu persyaratan dengan cara yang sangat jelas, memberikan bentuk keseluruhan yang pada dasarnya diinginkan oleh pelanggan untuk sistem dapatkan, atau cara lain untuk melihatnya adalah bahwa pelanggan menggambarkan apa sistem itu. Jika Anda ingin agar pelanggan Anda memikirkan hal-hal sedikit lebih jauh, Anda kemudian dapat meminta mereka untuk menggambarkan aturan yang harus dipatuhi fitur dengan menggunakan sejumlah pernyataan yang mirip dengan:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Lagi deskripsi yang sangat jelas, kali ini tentang caranyasistem harus berperilaku. Masalahnya, ini tidak akan menggantikan kebutuhan pengembang perangkat lunak untuk mengisi semua bagian yang kosong, dan untuk menggali rincian lebih lanjut yang mungkin hanya disadari oleh pelanggan secara periferal. Sementara pelanggan mungkin dapat 'dilatih' oleh programmer untuk menggambarkan fitur dan perilaku dalam format ramah-programmer yang bagus, pelanggan tidak akan benar-benar memiliki keterampilan atau pengetahuan untuk menghasilkan kasus uji yang bermakna, atau untuk menyediakan implementasi kode. Ini saya kira poin dari artikel Martin Fowler yang disebut OP. Jadi ya, perangkat lunak itu sendiri tidak dapat ditulisi oleh pelanggan, tetapi deskripsi dari perangkat lunak yang paling pasti dapat - dan IMHO harus - ditulis oleh pelanggan. Untuk apa nilainya, saya tidak membaca artikel Fowler yang mengatakan bahwa pelanggan tidak boleh

Saya merasa bahwa kita programmer kadang-kadang bisa lupa bahwa pelanggan kita umumnya sangat pintar dalam hal pemahaman mereka tentang bisnis mereka dan proses bisnis, tentu jauh lebih baik daripada kita. Ketika mereka tidak memiliki programmer untuk memberi tahu mereka cara membangun sistem perangkat lunak, pelanggan biasanya menggunakan cara lain - mungkin kurang efisien - untuk menyelesaikan masalah manajemen bisnis khusus mereka. Maksud saya ini adalah basis data sederhana (pikirkan Access) atau spreadsheet, atau bahkan dalam buku besar yang ditulis tangan, dan dengan aturan dan prosedur yang jelas untuk mengelola proses-proses tersebut. Apa yang tidak dimiliki oleh banyak pelanggan bukanlah cara untuk menentukan bagaimana suatu sistem perlu bekerja, melainkan bagaimana ia harus dibangun , dan yang lebih penting seberapa efisien menggambarkan aturan perilaku suatu sistem kepada orang-orang yangmemang memiliki keterampilan untuk benar-benar membangun sistem.

Jika memang ada konsensus tentang kurangnya kemampuan menulis, apakah Anda akan melihat masalah dengan alat yang, alih-alih memulai dengan skenario dan menginstruksikannya, akan menghasilkan skenario yang dapat dibaca bisnis dari tes yang sebenarnya?

Saya pikir ini melihat masalah dengan cara yang salah. Saya akan melihat masalah besar dengan alat yang menghasilkan dokumentasi dari tes jika dokumentasi itu dimaksudkan untuk mewakili spesifikasi dengan cara apa pun. Untuk menguji suatu skenario, Anda perlu memahaminya, oleh karena itu, skenario tersebut harus sudah ada untuk Anda berdua menentukan tes untuk itu. Jika Anda menggambarkan skenario dalam sintaks BDD, maka Anda telah menentukannya, dan dengan demikian Anda hanya dapat instrumen skenario setelah fakta. Jika di sisi lain Anda memiliki alat yang akan memungkinkan pelanggan untuk menggambarkan suatu sistem dalam DSL ramah pemrograman yang bagus, dan jika alat itu dapat digunakan untuk menghasilkan templat kode yang akan digunakan sebagai test suite, maka saya akan d mengatakan akan ada nilai besar dalam alat seperti itu. Itu tidak akan melihat pelanggan mengambil programmer dari persamaan, dan itu akan membantu mengurangi upaya yang diperlukan untuk mengambil keinginan pelanggan dan menghasilkan persyaratan uji-disandikan dalam mode BDD, dan mungkin akan membuat keinginan pelanggan lebih mudah dipahami. Namun itu tidak akan menjadi pengganti untuk memiliki pengembang perangkat lunak yang berpengalaman di tangan untuk membantu pelanggan untuk memisahkan kebutuhan pelanggan dari keinginan pelanggan.


“Untuk menguji suatu skenario, kamu perlu memahaminya, oleh karena itu, skenario tersebut harus sudah ada untukmu untuk menentukan tes untuk itu.” Aku setuju. Yang saya pertanyakan adalah apakah menegakkan batasan bahasa bernilai apa-apa. Saya tidak mengklaim kita harus menulis hanya tes; tetapi saya bertanya-tanya apakah kita tidak boleh menerima kenyataan bahwa uraian bisnis akan (dan mungkin seharusnya) selalu berupa uraian formulir yang jelas dan bebas . Karenanya, kami memiliki uraian bisnis murni, dan menghasilkan skenario yang dapat dibaca, membiarkan manusia memutuskan apakah cocok; daripada berpura-pura kita menggunakan descs sebenarnya untuk menguji.
MattiSG

@MattiSG ...whether enforcing language constraints is worth anything. Ini pertanyaan yang bagus. Deskripsi bentuk bebas lebih ekspresif dan alami bagi penulis, tetapi menghasilkan komentar bertele-tele yang membutuhkan pembedahan untuk mendapatkan spesifikasi yang berguna. Dengan mendefinisikan 'aturan' formal (alias DSL) untuk persyaratan dan spesifikasi penulisan, Anda memiliki bahasa yang sama yang dapat dipahami oleh pelanggan dan pemrogram, sehingga membatasi kesalahpahaman. Jika Anda mendapatkan deskripsi yang benar, mereka dapat digunakan kata demi kata sebagai templat untuk pengujian Anda. Jadi tidak perlu alat kompleks untuk "menghasilkan" apa pun.
S.Robins

@MattiSG FWIW, menggunakan DSL dan BDD adalah sistem yang saya gunakan sendiri. Persyaratan didefinisikan sebagai pernyataan Entitas-Fitur-Manfaat, dan ditindaklanjuti dengan spesifikasi yang memperpanjang pernyataan persyaratan awal menggunakan pernyataan AAA (Yaitu: Diberikan Ketika-Lalu) ... pada dasarnya pernyataan skenario. Kesulitan ketika mencoba memecahkan kode teks bebas adalah bahwa tanpa DSL, Anda tidak memiliki sarana yang mudah untuk mendefinisikan suatu algoritma yang dapat menghasilkan skenario pengumpulan yang bermakna. Maksud saya adalah bahwa menggunakan tes sebagai titik awal untuk menghasilkan skenario agak mundur.
S.Robins

5

Saya telah melihat pengembang menulis skenario; penguji menulis skenario dan bahkan pemilik produk menulis skenario. Saya juga memiliki percakapan yang secara eksplisit dirancang untuk menghasilkan skenario - "Mengingat <konteks lain ini>, kapan lagi yang harus terjadi?" - dan menuliskan kata-kata yang digunakan bisnis.

Hasil terbaik yang saya miliki adalah dari memiliki percakapan dengan pemilik produk saat dia berada di kantor, menangkap mereka di wiki kemudian mengirimkannya kepadanya sehingga dia dapat memperbaiki dan menambahkan lebih banyak. Dia menemukan pasangan yang kami lewatkan dalam percakapan kami. Itu mengguncang.

Skenario terburuk yang pernah saya lihat adalah yang ditulis sendiri oleh pengembang tanpa percakapan dengan bisnis. Saya tahu karena mereka menggunakan istilah seperti "Ketika saya melakukan pencarian", atau "Ketika saya mengirimkan formulir dengan tanggal hari ini + 3". Mereka biasanya skenario yang tidak terlalu menarik, terlalu banyak dari mereka, tingkat detail terlalu rendah dan karenanya benar-benar tidak dapat dipertahankan. Bisnis juga tidak membaca ini.

Jauh lebih baik untuk fokus pada percakapan IMO. Saya telah melihat beberapa tim melakukan ini sekarang selama beberapa bulan dengan peningkatan besar pada kualitas, terlepas dari otomatisasi. Satu tim berhasil membuat otomatisasi bekerja di lingkungan yang sangat sulit beberapa minggu kemudian, sangat menyenangkan bagi penguji! Tapi sungguh, selama tim melakukan percakapan dan menggunakan skenario untuk menggambar skenario lain, saya tidak berpikir siapa yang menulisnya.


+1 Komunikasi benar-benar adalah kuncinya, dan skenario benar-benar perlu dalam istilah bahwa orang-orang bisnis kita, sehingga sesuai dengan pertanyaan OPs, jika kita membuat DSL, ini benar-benar harus dapat menjadi pertandingan yang lebih dekat untuk apa yang akan dikatakan pelanggan, dan bukan apa yang dipikirkan oleh pemrogram, pelanggan harus mengatakan.
S.Robins

0

Pengalaman saya adalah bahwa sebaiknya diserahkan kepada BA (Analis Bisnis) untuk menulis GWT ( Diberi Ketika-Lalu ) (pengalaman menggunakan SpecFlow). BA dapat menerjemahkan persyaratan Pelanggan ke dalam GWT dan bisnis dapat membacanya. Pelanggan memahami sistem tetapi mereka tidak memiliki teknologi berpikir untuk menulis persyaratan dengan cara yang dapat kita gunakan.

Idealnya BA akan menulis beberapa GWT, saya akan membuat beberapa revisi, BA akan meninjau / merevisi ulang sampai BA dan bisnis percaya diri dalam liputan. Praktis BA akan memberi saya konsep kasar bahwa saya akan membersihkan dan membuat pekerjaan. Bisnis itu mengabaikannya dan berkata, lalu bertanya-tanya mengapa itu tidak mencakup beberapa area yang tidak dipikirkan oleh siapa pun.


Bisakah Anda jelaskan apa arti GWT bagi Anda? :)
MattiSG

@MattiSG: tebak itu untuk Given-When-Then (lihat OP).
sleske

@MattiSG - Memperbarui tangkapan yang bagus.
SoylentGray
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.