2.3.3

 

Dalam pengembangan perangkat lunak, bug merupakan konsekuensi alami dari kompleksitas sistem yang melibatkan banyak aturan, kombinasi logika, dan asumsi manusia. Di industri seperti e-commerce dan fintech, risiko akibat bug jauh lebih tinggi dibanding sektor lain karena berhubungan langsung dengan hal-hal krusial seperti:

●      Transaksi keuangan pengguna (fintech),

●      Diskon, promo, dan loyalitas pelanggan (e-commerce),

●      Data sensitif dan reputasi platform.

Pada perangkat lunak, bug bisa muncul dari berbagai penyebab, diantaranya:

●      Perbedaan pemahaman antara Product Owner (PO) dan developer mengenai aturan bisnis,

●      Implementasi logika yang tidak lengkap, misalnya lupa menghitung biaya admin,

●      Kombinasi edge case yang tidak diuji,

●      Perubahan kecil pada UI/UX yang berdampak besar pada perilaku pengguna.

Sebagai ilustrasi, di sebuah startup fintech, seorang pengguna mencoba melakukan transfer saldo tepat dengan jumlah nominal yang diminta. Namun, sistem menolak transaksi tersebut tanpa alasan yang jelas. Setelah ditelusuri, ditemukan adanya biaya administrasi tersembunyi yang tidak ditampilkan kepada pengguna, sehingga sistem menolak tanpa memberikan pesan error yang informatif. Kasus ini bukan sekadar bug teknis, melainkan juga merupakan kegagalan UX dan komunikasi antar tim.

Behavior-Driven Development (BDD) hadir sebagai solusi untuk menjembatani kesenjangan ini. BDD mendorong semua pihak (PO, QA, developer, bahkan customer support) untuk menuliskan ekspektasi sistem dalam bentuk skenario perilaku menggunakan bahasa sederhana (Gherkin).

Skenario BDD memiliki karakteristik eksplisit, terdokumentasi dengan baik, dan bisa diuji secara otomatis. Hal ini mempermudah pencegahan bug karena:

●      QA memiliki acuan yang jelas untuk membuat automation test.

●      Developer memahami ekspektasi nyata pengguna yang harus dipenuhi.

●      PO bisa mengevaluasi apakah fitur akan memenuhi kebutuhan bisnis.

Jika terjadi bug, tim dapat dengan cepat menelusuri skenario yang gagal dan memperbaiki kode berdasarkan perilaku yang tidak terpenuhi, sehingga bukan hanya memperbaiki kode secara parsial. Dengan BDD, bug tidak hanya dideteksi, tapi juga dicegah sejak awal.

 

Selain menyelaraskan komunikasi antar tim, BDD juga fokus pada perilaku nyata sistem, sehingga efektif untuk mencegah bug. Berikut alasan mengapa BDD sangat relevan dalam pengujian modern, khususnya di industri e-commerce dan fintech: Bug sering kali muncul akibat asumsi yang tidak tersampaikan dengan jelas antar tim. BDD membantu menyelaraskan ekspektasi antara tim teknis dan non-teknis melalui skenario bersama. Industri e-commerce dan fintech rentan terhadap bug di edge case, misalnya diskon yang berlaku di hari tertentu, limit transfer yang berbeda antar user tier, atau kombinasi kode promo yang kompleks. BDD mendorong automated testing yang lebih bermakna karena test case disusun berdasarkan apa yang pengguna lakukan, bukan hanya apa yang sistem bisa lakukan. Setiap bug yang ditemukan dapat ditelusuri kembali ke skenario BDD yang gagal. Hal ini membantu memberikan traceability dalam audit, debugging, dan regresi.

Kasus 1: Bug Promo Diskon Tidak Terpakai (E-Commerce)

Sebuah e-commerce lokal mengadakan promo otomatis dengan ketentuan:
“Jika total belanja lebih dari Rp500.000 dan memilih metode pembayaran ShopeePay, maka secara otomatis akan mendapatkan diskon 10%.”

Bug yang Terjadi:

Beberapa pelanggan melaporkan bahwa mereka tidak mendapatkan diskon, meskipun total belanja sudah memenuhi syarat dan metode pembayaran sudah sesuai.

Penyebab:

●      Developer hanya menerapkan logika promo hanya untuk total harga produk, tanpa menghitung ongkos kirim dan layanan tambahan.

●      QA hanya menguji skenario utama (happy path) tanpa memeriksa edge case, seperti pengguna menambahkan barang senilai Rp495.000 + ongkos kirim Rp20.000.

●      Tidak ada dokumentasi eksplisit mengenai aturan apakah harga dihitung berdasarkan subtotal produk atau total akhir pembayaran.

Solusi dengan BDD:
QA menuliskan ulang skenario dengan format Gherkin berikut:

Feature: Promo diskon otomatis saat checkout   Scenario: Pengguna mendapat diskon saat subtotal melebihi Rp500.000     Given pengguna memasukkan produk senilai Rp510.000 ke cart     And memilih metode pembayaran ShopeePay     When pengguna masuk ke halaman checkout     Then sistem otomatis menambahkan diskon 10%     And total belanja mencerminkan potongan harga

Manfaat:

●      QA dan PO bisa mengevaluasi ulang definisi “subtotal”.

●      Developer memiliki acuan eksplisit untuk implementasi logika promo yang tepat.

●      Bug serupa bisa dicegah di pengujian regresi berikutnya karena tes ini bisa diotomatisasi.

Kasus 2: Transaksi Gagal karena Perbedaan Pembulatan Desimal (Fintech)

Dalam sistem dompet digital, pengguna bisa melakukan transfer dana dengan presisi dua desimal. Namun, backend menghitung biaya admin 1.5% tanpa pembulatan standar.

Bug yang Terjadi:

Transaksi senilai Rp100.000 gagal karena sistem menganggap saldo pengguna tidak cukup. Setelah dianalisis, ternyata backend menghitung biaya admin sebesar Rp1.500,0012, sehingga total yang dibutuhkan pengguna lebih dari Rp101.500.

Penyebab:

●      Developer backend menggunakan presisi penuh tanpa membulatkan nilai ke dua desimal.

●      QA tidak menguji transaksi dengan nominal tepat pada batas saldo.

●      Tidak ada skenario BDD untuk validasi perhitungan biaya admin.

Solusi dengan BDD:

Feature: Validasi transaksi dengan biaya admin   Scenario: Transfer berhasil ketika saldo mencukupi setelah biaya admin     Given saldo pengguna adalah Rp101.500     When pengguna mencoba transfer Rp100.000     Then transaksi berhasil     And sistem menampilkan biaya admin Rp1.500

Manfaat:

●      QA bisa membuat test case otomatis berdasarkan skenario.

●      Developer tahu batasan yang jelas dalam pengkodean agar sesuai standar pembulatan.

●      Setiap bug yang muncul bisa langsung di-trace ke langkah pengujian yang gagal.