Mengenal Gherkin: Bahasa yang Menyatukan Tim Bisnis, Developer, dan QA dalam Satu Pemahaman

Di dunia pengembangan perangkat lunak yang serba cepat, salah satu tantangan terbesar bukanlah tantangan teknis, melainkan tantangan komunikasi. Bayangkan skenario yang mungkin terlalu akrab ini: seorang manajer produk menjelaskan fitur baru dengan visinya, tim developer menafsirkannya ke dalam kode berdasarkan asumsi mereka, dan tim Quality Assurance (QA) mengujinya berdasarkan pemahaman mereka sendiri. Hasilnya? Sebuah produk yang secara teknis berfungsi, tetapi tidak sesuai dengan kebutuhan bisnis awal, yang berujung pada revisi tak berujung dan pemborosan waktu.

Masalah ini, yang sering disebut sebagai "Tower of Babel" dalam pengembangan perangkat lunak, muncul karena setiap tim berbicara dengan "bahasa" yang berbeda. Tim bisnis berbicara dalam bahasa kebutuhan pengguna dan ROI. Developer berbicara dalam bahasa logika, kelas, dan fungsi. Sementara itu, tim QA berbicara dalam bahasa kasus uji, skenario, dan edge cases.

Bagaimana jika ada sebuah "penerjemah universal"? Sebuah bahasa sederhana yang dapat dipahami oleh semua pihak, yang berfungsi sebagai kontrak dan sumber kebenaran tunggal? Inilah peran yang dimainkan oleh Gherkin. Gherkin bukanlah bahasa pemrograman, melainkan sebuah jembatan—sebuah sintaks yang dirancang untuk menyatukan semua pemangku kepentingan dalam satu pemahaman yang sama tentang bagaimana sebuah perangkat lunak seharusnya berperilaku.

Baca juga : Sevilla vs Getafe 1-2: Gol Bunuh Diri Tak Cukup Selamatkan Los Nervionenses

Apa Sebenarnya Gherkin?

Secara sederhana, Gherkin adalah sebuah bahasa dengan struktur sederhana (structured natural language) yang digunakan untuk mendeskripsikan perilaku sebuah aplikasi. Gherkin adalah komponen utama dari metodologi Behavior-Driven Development (BDD), sebuah pendekatan pengembangan di mana perangkat lunak dirancang dan dibangun berdasarkan perilaku yang diharapkan dari sudut pandang pengguna.

Penting untuk ditekankan: Gherkin sendiri tidak melakukan apa-apa. Ia hanyalah teks dalam sebuah file (biasanya dengan ekstensi .feature). Kekuatannya menjadi nyata ketika digunakan dengan alat seperti Cucumber, SpecFlow, atau Behave. Alat-alat inilah yang membaca file Gherkin dan menggunakannya untuk menjalankan tes otomatisasi yang memverifikasi bahwa kode yang ditulis oleh developer sesuai dengan perilaku yang dijelaskan.

Namun, manfaat utamanya terjadi jauh sebelum satu baris pun kode tes dieksekusi. Manfaat tersebut lahir dari proses penulisan skenario Gherkin itu sendiri, yang mendorong percakapan dan kolaborasi.

Anatomi Gherkin: Membedah Sintaks Given-When-Then

Keindahan Gherkin terletak pada kesederhanaannya. Strukturnya dirancang agar dapat dibaca dan ditulis oleh siapa saja, bahkan oleh mereka yang tidak memiliki latar belakang teknis. Struktur ini berpusat pada beberapa kata kunci utama.

Mari kita bedah anatominya menggunakan contoh umum: fitur login pada sebuah situs e-commerce.

Gherkin

# Nama file: login.feature

Feature: Login Pengguna
  Sebagai seorang pengguna terdaftar,
  Saya ingin bisa masuk ke akun saya,
  Agar saya dapat mengakses riwayat pesanan saya.

  Scenario: Login berhasil dengan kredensial yang valid
    Given saya berada di halaman login
    And saya telah memasukkan username "userbenar"
    And saya telah memasukkan password "passbenar123"
    When saya menekan tombol "Login"
    Then saya seharusnya dialihkan ke halaman dashboard
    And saya melihat pesan selamat datang "Selamat datang, userbenar!"

Mari kita pecah setiap bagian:

• Feature: Menjelaskan fungsionalitas tingkat tinggi yang sedang dideskripsikan. Bagian deskripsi di bawahnya (Sebagai..., Saya ingin..., Agar...) membantu memberikan konteks bisnis dan nilai dari fitur tersebut.
• Scenario: Ini adalah contoh konkret dari sebuah perilaku. Satu Feature bisa memiliki banyak Scenario untuk mencakup berbagai kasus (misalnya, login gagal, lupa password, dll.).
• Given (Kondisi Awal): Menjelaskan konteks atau prasyarat sebelum sebuah aksi terjadi. Ini adalah "panggung" di mana skenario akan berlangsung. Dalam contoh ini, penggunanya harus sudah berada di halaman login.
• When (Aksi): Menjelaskan tindakan spesifik yang dilakukan oleh pengguna atau sistem. Ini adalah pemicu dari perilaku yang akan diuji.
• Then (Hasil yang Diharapkan): Menjelaskan hasil yang seharusnya terjadi setelah aksi pada When dilakukan. Ini adalah bagian verifikasi, di mana kita menegaskan bahwa sistem berperilaku seperti yang diharapkan.
• And dan But: Digunakan untuk menambahkan beberapa langkah pada Given, When, atau Then agar skenario lebih mudah dibaca tanpa harus mengulang kata kunci utama.

Dengan struktur ini, siapa pun di dalam tim dapat membaca skenario di atas dan langsung mengerti persis apa yang seharusnya terjadi.

Gherkin in Action: Sebuah Sesi Kolaborasi Tiga Pihak

Bayangkan sebuah rapat perencanaan fitur baru. Di dalam ruangan ada:

1. Ana, seorang Product Owner (PO).
2. Budi, seorang Developer.
3. Citra, seorang QA Engineer.

Ana memulai dengan menjelaskan, "Kita butuh pengguna bisa login."

Tanpa Gherkin, Budi mungkin akan langsung berpikir tentang database, enkripsi password, dan API. Citra akan mulai membayangkan kasus uji: password salah, username kosong, tombol login dinonaktifkan. Masing-masing sudah membangun interpretasi sendiri.

Dengan Gherkin, prosesnya berbeda. Ana, Budi, dan Citra membuka file .feature bersama-sama.

• Ana (PO) menulis Feature dan Scenario dasar.
• Citra (QA) bertanya, "Bagaimana jika passwordnya salah? Pesan apa yang muncul?" Mereka pun menambahkan skenario baru: Scenario: Login gagal dengan password yang salah.
• Budi (Developer) menambahkan, "Sistem kita memblokir akun setelah 3 kali gagal login. Perlu kita masukkan sebagai skenario juga?" Mereka setuju dan menambahkannya.

Di akhir sesi 30 menit tersebut, mereka memiliki beberapa skenario Gherkin yang jelas dan disepakati bersama. Dokumen ini menjadi kontrak mereka. Budi tahu persis apa yang harus ia bangun. Citra tahu persis apa yang harus ia uji. Ana yakin bahwa fitur yang akan dibuat sesuai dengan visinya. Tidak ada lagi ruang untuk ambiguitas.

Manfaat Nyata di Luar Kode

Mengadopsi Gherkin dan BDD memberikan keuntungan yang jauh melampaui sekadar otomatisasi pengujian:

1. Mengurangi Ambiguitas: Bahasa Gherkin memaksa tim untuk berpikir dan berkomunikasi secara konkret. Konsep yang kabur harus diubah menjadi contoh Given-When-Then yang spesifik.
2. Dokumentasi Hidup (Living Documentation): File .feature menjadi dokumentasi yang paling akurat tentang bagaimana sistem Anda bekerja. Karena terhubung langsung dengan tes otomatisasi, dokumentasi ini tidak akan pernah usang. Jika kode berubah dan menyebabkan skenario gagal, tim dipaksa untuk memperbarui file Gherkin atau memperbaiki kodenya.
3. Fokus pada Pengguna: Dengan selalu dimulai dari Feature dan Scenario dari sudut pandang pengguna, tim secara alami akan membangun produk yang lebih berpusat pada pengguna.
4. Mempercepat Onboarding: Anggota tim baru—baik itu developer, QA, atau manajer produk—dapat membaca repositori file .feature untuk mendapatkan pemahaman yang cepat dan akurat tentang fungsionalitas aplikasi.

Baca juga : Universitas Teknokrat Indonesia Dapatkan Penghargaan Mitra Kerja Dari Kemkumham

Kesimpulan: Membangun Jembatan, Bukan Sekadar Perangkat Lunak

Pada akhirnya, kekuatan sejati Gherkin bukanlah pada sintaksnya, melainkan pada filosofi kolaborasi yang dibawanya. Ia mengubah proses pengembangan perangkat lunak dari serangkaian serah terima yang terputus-putus menjadi sebuah percakapan yang berkelanjutan. Ia memaksa terjadinya dialog, menyelaraskan perspektif, dan membangun empati di antara peran-peran yang berbeda.

Penulis : helen putri marsela