2.3.1

Dalam dunia pengembangan perangkat lunak modern yang bergerak dengan cepat, kolaborasi erat antara tim bisnis dan teknis semakin penting. Salah satu pendekatan yang menjembatani kedua pihak tersebut adalah Behavior-Driven Development (BDD). Metode ini memungkinkan pengujian dilakukan menggunakan bahasa sehari-hari yang mudah dipahami oleh semua pemangku kepentingan, mulai dari developer, QA, Product Owner, hingga pengguna akhir. Dengan begitu, test yang dibuat dapat dipahami oleh semua orang, baik pihak teknis maupun non teknis.

BDD tidak sekadar menulis test case dengan format Given-When-Then. Lebih dari itu, BDD menekankan pentingnya pemahaman bersama mengenai kebutuhan sistem melalui spesifikasi berbasis perilaku. Dengan cara ini, implementasi fitur benar-benar sesuai dengan kebutuhan pengguna dan kualitas aplikasi dapat terjaga sejak awal proses pengembangan.

Di sisi lain, kemajuan teknologi Artificial Intelligence (AI) membawa perubahan signifikan dalam dunia QA. Saat ini, tersedia alat berbasis AI yang mampu secara otomatis membuat skenario uji (test scenario) dari berbagai sumber, seperti dokumentasi produk, user story, hingga wireframe. Proses yang sebelumnya dilakukan secara manual kini menjadi jauh lebih cepat dan akurat.

Penggabungan antara BDD dan pembuatan test case otomatis berbasis AI membuka peluang besar bagi QA Engineer dan tim pengembang untuk meningkatkan efisiensi, tingkat akurasi, dan cakupan pengujian (testing coverage). Selain mempercepat penulisan skenario uji, AI juga membantu memastikan bahwa tidak ada skenario penting yang terlewatkan, terutama pada aplikasi yang kompleks dan terus berkembang.

Gambar 2.3.1 Konsep BDD

Behavior-Driven Development (BDD) adalah sebuah pendekatan dalam pengembangan perangkat lunak yang berfokus pada kolaborasi dan komunikasi antara tim teknis (developer, QA) dan non-teknis (product owner, stakeholder bisnis) melalui bahasa yang mudah dipahami oleh semua pihak. Tujuan utama BDD bukan sekadar menguji sistem, tetapi lebih kepada menyepakati perilaku sistem yang diinginkan sebelum proses pengembangan dimulai.

Behavior-Driven Development (BDD) adalah pengembangan dari metode Test-Driven Development (TDD), dengan cakupan yang lebih luas. TDD sendiri merupakan metode pengembangan perangkat lunak di mana fokus utamanya adalah menulis pengujian otomatis dalam bentuk unit test sebelum menulis kode aktual untuk suatu fitur dalam aplikasi atau produk. Pendekatan ini menggunakan siklus pengembangan singkat yang diulang-ulang untuk memverifikasi kualitas dan kebenaran kode. Jika TDD berfokus pada penulisan unit test oleh developer untuk memastikan fungsi kode berjalan sesuai harapan, maka BDD melibatkan seluruh pihak terkait agar bekerja sama dan memiliki pemahaman sama mengenai kebutuhan pengguna akhir.

1.    Mendefinisikan perilaku sistem dari sudut pandang pengguna
Fokus BDD adalah apa yang dilakukan sistem, bukan bagaimana sistem dibangun. Pendekatan ini membuat spesifikasi lebih relevan bagi kebutuhan bisnis dan proses QA.

2.    Menggunakan format Gherkin untuk mendeskripsikan skenario
Gherkin adalah bahasa semi-natural yang terdiri dari Given-When-Then, yang memungkinkan semua pihak untuk memahami dan menyepakati ekspektasi perilaku sistem secara jelas.

3.    Menghubungkan user story dengan testing
Skenario BDD biasanya diturunkan langsung dari user story dan dapat langsung digunakan sebagai dasar untuk pengujian, baik manual maupun otomatis.

4.    Dapat diintegrasikan ke tools otomasi
BDD dapat diintegrasikan dengan berbagai tools otomasi seperti Cucumber, SpecFlow, atau Behave, yang mampu membaca skenario Gherkin dan mengeksekusinya sebagai automated test scripts.

Format Gherkin dan Struktur Skenario BDD

Spesifikasi kebutuhan dalam BDD disusun dalam bentuk skenario menggunakan format Gherkin. Gherkin adalah bahasa semi-natural yang mudah dibaca oleh manusia sekaligus bisa diproses secara otomatis oleh mesin, sehingga memudahkan komunikasi lintas tim. Hal ini, memudahkan komunikasi antar tim tanpa hambatan teknis.

Contoh:

user story:

As a [regular user]

I want to [login to my dashboard]

So that [I can access all features on my dashboard]

Dengan format ini, semua pihak, termasuk yang tidak memiliki latar belakang teknis, dapat dengan mudah membaca dan memahami apa yang diuji serta bagaimana sistem seharusnya berperilaku.

Mengapa BDD Penting?

●      Meningkatkan Kolaborasi dan Pemahaman Bersama
Sering kali terjadi kesenjangan komunikasi antara pengembang dan pemilik produk sehingga fitur yang dibuat tidak sesuai harapan. Dengan spesifikasi yang jelas dan terstruktur dalam BDD, semua pihak dapat memiliki pemahaman yang sama mengenai apa yang harus dikembangkan dan diuji.

●      Mendukung Agile dan DevOps
Skenario BDD dapat dengan mudah diintegrasikan ke dalam pipeline continuous integration dan continuous delivery (CI/CD), sehingga proses definisi dan pengujian perilaku aplikasi bisa berjalan secara otomatis dan berulang.

●      Meningkatkan Kualitas Produk
Pendekatan ini mengurangi risiko miskomunikasi dan memastikan cakupan pengujian meliputi fungsi-fungsi yang benar-benar penting bagi pengguna karena fokusnya pada perilaku sistem dari sudut pandang pengguna.

Dengan demikian, BDD bukan hanya sekedar teknik menulis skenario, tetapi juga alat strategis untuk mempercepat kolaborasi, meningkatkan kualitas, serta mendukung proses pengembangan yang gesit dan terintegrasi.

Tantangan Penerapan BDD

●      Menulis skenario dengan menggunakan format Gherkin memakan waktu dan sulit dilakukan

Menulis skenario menggunakan format Gherkin membutuhkan kejelasan pada user story serta pengalaman menulis perilaku yang relevan dan mudah dipahami oleh semua pihak.

●      Dokumentasi seringkali ambigu

Apabila tim produk tidak menyediakan spesifikasi yang jelas dan lengkap, maka QA dan developer akan mengalami kesulitan dalam menyusun skenario yang tepat dan akurat.

●      Masalah skalabilitas

Dalam proyek besar dengan banyak fitur, menyusun dan memelihara ratusan bahkan ribuan skenario pengujian dapat menjadi beban berat yang memerlukan perhatian khusus dari tim.

          Memahami dan menyadari tantangan-tantangan tersebut, membantu tim pengembang dan QA dalam membuat strategi untuk mengatasinya, sehingga penerapan BDD dapat berjalan lebih efektif dan memberikan hasil yang optimal.

Peran AI dalam Pengembangan Test Case

Di era Quality Assurance (QA) modern, kehadiran Artificial Intelligence (AI) membawa perubahan besar dalam proses pengembangan test case, khususnya skenario berbasis Gherkin. AI memungkinkan pembuatan skenario pengujian secara otomatis dari berbagai sumber input, seperti user story di Jira, desain UI dari Figma, dokumentasi Product Requirement Document (PRD), hingga screenshot atau flow diagram. Beberapa contoh tools yang memanfaatkan kemampuan AI ini antara lain:

●      TestSigma: Mengubah deskripsi fitur menjadi skenario Gherkin lengkap dengan test case siap dijalankan.

●      Functionize: Menghasilkan test case dari prototipe UI dengan menggunakan bantuan AI.

●      Mabl & Testim.io: Merekam interaksi pengguna dan secara otomatis menyarankan skenario uji.

●      Copilot for Test / ChatGPT: Dapat diberi prompt berupa user story dan menghasilkan skenario Gherkin yang siap pakai.

Dengan bantuan AI, penulisan skenario yang biasanya memakan waktu berjam-jam kini dapat dipercepat menjadi dalam hitungan detik. Meski begitu, peran QA tetap sangat penting untuk melakukan validasi agar skenario yang dihasilkan relevan dan akurat, baik dari sisi bisnis maupun teknis. Adapun beberapa keunggulan dari dari skenario yang dihasilkan AI (AI-Generated Scenario) antara lain:

●      Mengotomatisasi proses penulisan skenario
AI mampu menganalisis sumber, seperti user story, PRD, atau bahkan UI prototipe untuk menghasilkan skenario Given-When-Then yang relevan.

●      Menghemat waktu dan tenaga QA
Proses yang biasanya membutuhkan waktu berjam-jam menjadi jauh lebih singkat, sehingga QA dapat lebih fokus pada validasi dan eksplorasi uji.

●      Mempercepat adopsi BDD di tim yang belum terbiasa
Bagi tim yang baru mengenal Behavior-Driven Development (BDD), AI dapat membantu memulai dengan memberikan saran skenario awal yang bisa dikembangkan lebih lanjut.

Meskipun AI dapat membantu menghasilkan skenario secara otomatis, validasi dari manusia tetap sangat penting karena hasil AI tidak selalu sesuai konteks atau kebutuhan bisnis. Oleh karena itu, QA tetap bertanggung jawab untuk memastikan skenario yang dibuat akurat dan relevan. Dengan demikian, AI bukan menggantikan peran QA, melainkan menjadi alat bantu yang mempercepat dan memudahkan proses pembuatan test case sekaligus menjaga kualitas pengujian secara menyeluruh.

Integrasi BDD, AI, dan QA Automation

Pemanfaatan Artificial Intelligence (AI) dalam pembuatan skenario Gherkin tidak hanya mempercepat proses penulisan test case, tetapi juga memperkuat implementasi Behavior-Driven Development (BDD) melalui integrasi dengan tools QA automation. Berikut adalah alur kerjanya:

1. Tim produk membuat user story.
2. AI membaca user story dan mengkonversinya menjadi skenario Gherkin.
3. Skenario tersebut kemudian dikonversi menjadi skrip automated test, menggunakan Cucumber, SpecFlow, atau Behave.
4. Skrip dijalankan dalam pipeline Continuous Integration/Continuous Delivery (CI/CD).
5. Tim menerima feedback secara cepat jika terdapat perilaku sistem yang tidak sesuai dengan ekspektasi.

Alur ini membantu perusahaan menerapkan prinsip Shift Left Testing secara optimal, yang bertujuan untuk mendeteksi kesalahan lebih awal, mengurangi biaya debugging, dan mempercepat waktu peluncuran produk ke pasar.

Perkembangan teknologi, khususnya AI, telah memperkaya praktik BDD dan QA automation. Integrasi AI, BDD, dan QA automation dapat meningkatkan efektivitas pengujian sekaligus mendukung proses pengembangan perangkat lunak yang lebih cepat dan berkualitas. Dalam praktik industri, hal ini terlihat melalui beberapa manfaat berikut:

●      Mendorong kolaborasi lintas fungsi
Skenario BDD mempermudah komunikasi antara QA, developer, dan Product Owner karena semua pihak dapat membaca dan memahami test case yang sama.

●      Mempercepat feedback loop dalam agile/scrum
Skenario yang dihasilkan dan dijalankan secara otomatis dalam CI/CD pipeline memungkinkan tim untuk segera mengetahui adanya error atau ketidaksesuaian dengan cepat.

●      Meningkatkan traceability dan dokumentasi
Skenario BDD dapat langsung dilacak ke user story (misalnya di Jira), sehingga sehingga hubungan antara kebutuhan bisnis dan pengujian menjadi lebih transparan dan kuat.

Dengan demikian, BDD menjadi pondasi kolaborasi yang mendukung pengembangan perangkat lunak yang cepat, berkualitas, dan adaptif, terutama dengan dukungan teknologi AI dan otomatisasi.

⬛ Studi Kasus: Pengembangan Fitur "Promo Otomatis" di Aplikasi E-Commerce

Sebuah perusahaan e-commerce berskala nasional sedang mengembangkan fitur baru, yaitu:

“Promo otomatis akan ditambahkan pada halaman checkout apabila pengguna memenuhi syarat tertentu, misalnya melakukan pembelian minimal Rp300.000 dengan menggunakan metode pembayaran tertentu.

Tim pengembang terdiri dari Product Owner, Developer, QA Manual dan Automation.

Proses Manual (Tanpa AI dan Tanpa BDD)

1. QA membaca user story dari Jira (yang sering kali singkat dan ambigu).
2. QA bertanya ke PO dan developer untuk melengkapi informasi.
3. QA menulis test case manual dalam Excel atau Xray.
4. Setelah fitur selesai dikembangkan, QA menjalankan test case.
5. Jika ditemukan gap, QA akan melaporkannya kepada developer, yang dapat menyebabkan proses feedback loop menjadi lambat.

Format regular test case:

Masalah:

●      Proses lambat, banyak interpretasi berbeda.

●      Dokumentasi test case tidak reusable.

●      Tidak bisa dijalankan otomatis (karena tidak dalam format scripting).

Proses dengan BDD dan AI-Generated Scenario

1. PO menuliskan user story di Jira seperti:
    "Sebagai pengguna, saya ingin mendapatkan promo otomatis jika belanja saya ≥ Rp300.000 dan membayar dengan e-wallet."
2. QA membuka AI Test Assistant (misalnya ChatGPT atau Github Copilot), lalu memasukkan user story.
3. AI menghasilkan skenario Gherkin secara instan:

4. QA hanya melakukan review dan adjust jika diperlukan.
5. Skenario ini langsung dimasukkan ke automation framework berbasis Cucumber dan dijalankan otomatis via Jenkins + Selenium.