Apakah BDD sebenarnya dapat ditulis oleh non-programmer?

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}
…

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.

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.

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.

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.