Banyak tim mengadopsi Gherkin dengan harapan besar untuk menjembatani komunikasi antara bisnis dan teknologi. Namun, tidak jarang adopsi ini berakhir dengan feature file yang membingungkan, sulit dipelihara, dan lebih terasa seperti "spesifikasi kaku" ketimbang skenario kolaboratif yang dinamis. Hasilnya, potensi Gherkin untuk menjadi alat yang presisi dan bermanfaat tidak tercapai.
Menulis Gherkin yang efektif adalah sebuah seni. Tujuannya bukan sekadar membuat tes otomatis berjalan, melainkan menciptakan deskripsi perilaku sistem yang jelas, ringkas, dan dapat dipahami oleh semua orang di dalam tim. Skenario yang "jitu" mampu menangkap esensi kebutuhan pengguna sekaligus menjadi dasar yang solid untuk automasi.
Berikut adalah 5 tips praktis untuk mengubah cara Anda menulis Gherkin, dari yang kaku menjadi skenario yang benar-benar jitu.
Baca juga : Warisan DCPU-16: Pelajaran dari CPU Virtual yang Gagal dan Potensinya di Masa Depan
1. Tulis dari Perspektif Pengguna, Bukan Penguji
Kesalahan paling umum adalah menulis skenario yang menjelaskan interaksi di level antarmuka (UI), seperti "klik tombol" atau "isi form". Pendekatan ini membuat skenario menjadi rapuh dan terlalu teknis. Gherkin yang baik berfokus pada tujuan atau niat pengguna.
- Mengapa ini penting? Tampilan antarmuka bisa berubah, tetapi tujuan pengguna cenderung stabil. Dengan fokus pada niat, skenario Anda menjadi lebih kuat terhadap perubahan UI dan lebih mudah dipahami oleh pemangku kepentingan non-teknis.
Contoh yang Kurang Baik (Imperatif):
Gherkin
Scenario: Login pengguna
Given saya berada di halaman login
When saya mengisi username "budi" di field "user_field"
And saya mengisi password "rahasia123" di field "pass_field"
And saya menekan tombol "login_button"
Then saya seharusnya melihat teks "Selamat datang, Budi!"
Contoh yang Baik (Deklaratif):
Gherkin
Scenario: Pengguna berhasil login
Given saya adalah pengguna terdaftar
When saya melakukan login dengan username "budi" dan password "rahasia123"
Then saya seharusnya berhasil masuk ke akun saya
And saya melihat pesan sambutan "Selamat datang, Budi!"
2. Gunakan Background untuk Konteks Berulang
Jika beberapa skenario dalam satu feature file memiliki langkah Given yang sama persis, jangan mengulanginya. Gunakan keyword Background untuk menetapkan konteks yang berlaku untuk semua skenario di dalamnya.
- Mengapa ini penting?
Backgroundmembuat skenario Anda lebih bersih, ringkas, dan fokus pada perilaku unik yang sedang diuji. Ini juga mengurangi duplikasi dan memudahkan pemeliharaan.
Contoh yang Kurang Baik (Duplikasi):
Gherkin
Feature: Manajemen Keranjang Belanja
Scenario: Menambah barang ke keranjang
Given saya sudah login sebagai pengguna "siti"
And saya memiliki keranjang belanja yang kosong
When saya menambahkan "Buku Pemrograman" ke keranjang
Then keranjang belanja saya seharusnya berisi 1 barang
Scenario: Menghapus barang dari keranjang
Given saya sudah login sebagai pengguna "siti"
And saya memiliki keranjang belanja yang kosong
And saya sudah menambahkan "Buku Pemrograman" ke keranjang
When saya menghapus "Buku Pemrograman" dari keranjang
Then keranjang belanja saya seharusnya kosong
Contoh yang Baik (Menggunakan Background):
Gherkin
Feature: Manajemen Keranjang Belanja
Background:
Given saya sudah login sebagai pengguna "siti"
And saya memiliki keranjang belanja yang kosong
Scenario: Menambah barang ke keranjang
When saya menambahkan "Buku Pemrograman" ke keranjang
Then keranjang belanja saya seharusnya berisi 1 barang
Scenario: Menghapus barang dari keranjang
Given saya sudah menambahkan "Buku Pemrograman" ke keranjang
When saya menghapus "Buku Pemrograman" dari keranjang
Then keranjang belanja saya seharusnya kosong
3. Satu Skenario, Satu Aturan Bisnis
Setiap skenario harus menguji satu aturan atau perilaku bisnis yang spesifik. Hindari membuat skenario "monster" yang mencoba menguji seluruh alur kerja dalam satu kali jalan.
- Mengapa ini penting? Skenario yang fokus lebih mudah dibaca, lebih cepat dieksekusi, dan lebih mudah untuk di-debug ketika terjadi kegagalan. Ketika sebuah tes gagal, Anda akan tahu persis aturan bisnis mana yang bermasalah.
Contoh yang Kurang Baik (Menguji Terlalu Banyak Hal):
Gherkin
Scenario: Proses checkout lengkap
Given saya memiliki barang di keranjang
When saya menuju halaman checkout
And saya mengisi alamat pengiriman
And saya memilih metode pembayaran "Transfer Bank"
And saya mengkonfirmasi pesanan
Then saya seharusnya melihat halaman "Terima Kasih"
And saya seharusnya menerima email konfirmasi
And stok barang seharusnya berkurang
Contoh yang Baik (Dipecal menjadi Skenario Fokus):
Gherkin
Scenario: Pengguna berhasil mengkonfirmasi pesanan
Given saya sudah mengisi alamat pengiriman dan memilih metode pembayaran
When saya mengkonfirmasi pesanan
Then saya seharusnya melihat halaman "Terima Kasih"
And pesanan saya tercatat di sistem
Scenario: Email konfirmasi terkirim setelah pesanan dibuat
Given sebuah pesanan telah berhasil dibuat oleh pengguna
When proses konfirmasi pesanan selesai
Then email konfirmasi seharusnya dikirimkan ke pengguna
Scenario: Stok barang berkurang setelah pesanan dikonfirmasi
Given sebuah pesanan telah berhasil dibuat
When pesanan tersebut dikonfirmasi
Then stok untuk barang yang dipesan seharusnya berkurang
4. Gunakan Bahasa Bisnis, Bukan Jargon Teknis
Ingat, Gherkin ditujukan untuk semua orang. Hindari menggunakan istilah teknis seperti "database", "API response", "validasi CSS", atau "endpoint". Terjemahkan konsep teknis ke dalam bahasa yang relevan dengan domain bisnis.
- Mengapa ini penting? Penggunaan bahasa bisnis memastikan bahwa analis bisnis dan pemilik produk dapat memvalidasi skenario tersebut dan benar-benar berkolaborasi dalam prosesnya.
Contoh yang Kurang Baik (Teknis):
Gherkin
Scenario: Validasi data pengguna baru
When saya mengirim request POST ke endpoint "/users"
Then saya seharusnya mendapat response code 201
And sebuah record baru harus dibuat di tabel 'users'
Contoh yang Baik (Berorientasi Bisnis):
Gherkin
Scenario: Pendaftaran pengguna baru berhasil
When saya mendaftarkan akun baru dengan informasi yang valid
Then sistem seharusnya mengenali saya sebagai pengguna terdaftar
5. Manfaatkan Scenario Outline untuk Data Beragam
Ketika Anda perlu menguji aturan bisnis yang sama dengan berbagai kombinasi data input dan output, gunakan Scenario Outline. Ini jauh lebih efisien daripada menyalin-tempel skenario yang sama berulang kali.
- Mengapa ini penting?
Scenario Outlinemenyajikan pengujian berbasis data dalam format tabel yang sangat mudah dibaca. Ini membuat cakupan tes menjadi jelas dan ringkas.
Contoh yang Kurang Baik (Skenario Berulang):
Gherkin
Scenario: Diskon untuk member Silver
Given saya adalah member dengan level "Silver"
And total belanja saya adalah Rp500.000
When saya melakukan checkout
Then saya seharusnya mendapatkan diskon sebesar Rp25.000
Scenario: Diskon untuk member Gold
Given saya adalah member dengan level "Gold"
And total belanja saya adalah Rp500.000
When saya melakukan checkout
Then saya seharusnya mendapatkan diskon sebesar Rp50.000
Contoh yang Baik (Menggunakan Scenario Outline):
Gherkin
Baca juga : Wakil Rektor UTI Presentasikan Penelitiannya di Parallel Session ICMEM 2025 di SBM ITB Bandung
Scenario Outline: Perhitungan diskon berdasarkan level member
Given saya adalah member dengan level "<Level>"
And total belanja saya adalah Rp500.000
When saya melakukan checkout
Then saya seharusnya mendapatkan diskon sebesar Rp<Diskon>
Examples:
| Level | Diskon |
| Silver | 25000 |
| Gold | 50000 |
| Platinum| 75000 |
Dengan menerapkan kelima tips ini, Anda dapat mengubah feature file Gherkin dari sekadar skrip pengujian menjadi aset kolaborasi yang kuat. Skenario yang jitu tidak hanya memastikan perangkat lunak bekerja sesuai harapan, tetapi juga memastikan seluruh tim memiliki pemahaman yang sama tentang harapan tersebut.
Penulis : helen putri marsela
