Dalam lingkup pengembangan perangkat lunak, celah antara apa yang dibayangkan oleh pemangku kepentingan dan apa yang dibangun oleh pengembang sering menjadi sumber gesekan besar. Ambiguitas dalam persyaratan menyebabkan pekerjaan ulang, rilis yang tertunda, dan tim yang frustasi. Untuk menutup kesenjangan ini, tim membutuhkan bahasa bersama yang tepat, mudah dibaca, dan dapat dieksekusi. Salah satu teknik paling efektif untuk mencapai kejelasan ini adalah Diberikan Ketika Maka sintaks. Pendekatan ini mengubah cerita pengguna yang samar menjadi spesifikasi konkret mengenai perilaku.
Ketika diterapkan dengan benar, metode ini berfungsi lebih dari sekadar latihan menulis; menjadi kontrak antara bisnis, tim desain, dan rekayasa. Ini menjamin bahwa setiap fitur yang dikirim sesuai dengan nilai yang dimaksudkan. Panduan ini mengeksplorasi mekanisme, manfaat, dan praktik terbaik dalam menggunakan Diberikan Ketika Maka untuk menentukan perilaku cerita pengguna secara efektif.
🧠 Memahami Struktur Inti
Pola Diberikan Ketika Maka merupakan komponen dasar dari Pengembangan Berbasis Perilaku (BDD). Ini menyusun kriteria penerimaan dengan cara yang meniru bahasa alami, sehingga mudah dipahami oleh pemangku kepentingan non-teknis, namun tetap cukup rinci untuk pengujian otomatis. Setiap bagian dari pola ini memiliki fungsi khusus dalam mendefinisikan siklus hidup suatu skenario.
- Diberikan: Menetapkan konteks atau keadaan awal. Ini menetapkan panggung dengan menggambarkan prasyarat yang diperlukan sebelum tindakan dilakukan.
- Ketika: Menggambarkan peristiwa atau tindakan khusus yang memicu perilaku. Ini adalah input atau rangsangan.
- Maka: Menentukan hasil atau dampak yang dapat diamati. Ini memverifikasi bahwa sistem berperilaku sesuai harapan setelah tindakan dilakukan.
Dengan memisahkan konteks, tindakan, dan hasil, tim dapat mengisolasi variabel dan memahami secara tepat bagian mana dari sistem yang bertanggung jawab atas perilaku tertentu. Modularitas ini mengurangi kompleksitas dan membuat proses debugging jauh lebih mudah.
📝 Mengurai Komponen-komponen
🏗️ Konteks ‘Diberikan’
Langkah Diberikan sering kali diabaikan, namun sangat penting untuk menetapkan lingkungan yang benar. Ini seharusnya tidak menggambarkan tindakan itu sendiri, melainkan keadaan sistem. Langkah Diberikan yang baik menjawab pertanyaan: ‘Apa yang harus benar sebelum kita mulai?’
Pertimbangkan nuansa dalam menulis bagian ini:
- Keadaan vs. Data: Bedakan antara keadaan aplikasi (misalnya, pengguna telah masuk) dan data yang ada (misalnya, pengguna memiliki saldo $100).
- Prasyarat: Daftar semua prasyarat yang diperlukan. Jika pembayaran gagal karena saldo tidak mencukupi, langkah Diberikan harus memastikan saldo benar-benar diperiksa.
- Kemudahan Bacaan: Buatlah bersifat deklaratif. Hindari bahasa imperatif seperti ‘Klik tombol.’ Sebaliknya, gunakan ‘Pengguna berada di dasbor.’
Ketika langkah Diberikan ambigu, pengujian akan gagal secara tidak terduga. Jika keadaan sistem tidak didefinisikan dengan jelas, otomasi bisa berjalan di lingkungan yang berbeda dari yang dimaksudkan, menyebabkan hasil negatif palsu.
🚀 Pemicu ‘Ketika’
Langkah Ketika mewakili interaksi. Ini adalah saat pengguna atau sistem memicu perubahan. Ini harus berupa tindakan tunggal dan atomik. Jika Anda menggabungkan beberapa tindakan menjadi satu langkah Ketika, akan sulit untuk mengidentifikasi bagian mana dari alur yang menyebabkan kegagalan.
Pertimbangan utama untuk bagian Ketika meliputi:
- Tanggung Jawab Tunggal: Fokus pada satu peristiwa per skenario. Jika Anda perlu menguji urutan peristiwa, pertimbangkan untuk membaginya menjadi skenario terpisah atau menggunakan Kerangka Skenario.
- Niat Pengguna:Bingkai tindakan dari sudut pandang pengguna atau batas sistem. “Pengguna mengirim formulir” lebih baik daripada “Tombol kirim diklik.”
- Waktu:Hindari istilah samar seperti “segera” atau “nanti.” Jelaskan secara spesifik tentang pemicunya.
📝 Hasil ‘Kemudian’
Langkah Kemudian adalah mekanisme verifikasi. Ini memastikan bahwa sistem merespons dengan benar terhadap langkah Ketika. Di sinilah proposisi nilai divalidasi.
Langkah Kemudian yang efektif harus:
- Dapat Diamati:Verifikasi sesuatu yang dapat dilihat atau diukur. Periksa elemen antarmuka pengguna, catatan basis data, atau respons API.
- Hindari Detail Implementasi:Fokus pada hasil, bukan logika internal. “Pesan konfirmasi muncul” lebih baik daripada “ID basis data ditingkatkan.”
- Cakup Kegagalan dan Kegagalan:Pastikan Anda menjelaskan apa yang terjadi jika tindakan gagal. “Kemudian pesan kesalahan ditampilkan” sepentingnya seperti “Kemudian pesanan ditempatkan.”
📊 Meningkatkan Kejelasan dengan Data Terstruktur
Untuk meningkatkan keterbacaan dan mengurangi pengulangan, tim sering menggunakan tabel dalam spesifikasi mereka. Ini sangat berguna saat menguji berbagai variasi perilaku yang sama dengan input data yang berbeda.
| Jenis Skenario | Fokus | Contoh |
|---|---|---|
| Jalur Bahagia | Alur keberhasilan standar | Diberikan kredensial yang valid, Ketika login dicoba, Maka dasbor ditampilkan. |
| Kasus Tepi | Kondisi batas | Diberikan kata sandi dengan 8 karakter, Ketika permintaan reset dilakukan, Maka kata sandi diterima. |
| Jalur Negatif | Penanganan kesalahan | Diberikan sesi yang telah kedaluwarsa, Ketika akses diminta, Maka terjadi alih halaman ke login. |
Menggunakan struktur ini memungkinkan pemangku kepentingan untuk meninjau persyaratan dengan cepat dan memahami cakupan yang dibutuhkan tanpa harus membaca paragraf-paragraf padat teks.
🚫 Kesalahan Umum yang Harus Dihindari
Bahkan dengan kerangka yang kuat, tim sering kali memasukkan kesalahan yang melemahkan efektivitas spesifikasi. Mengidentifikasi kesalahan-kesalahan ini sejak dini memastikan kelangsungan hidup dokumentasi.
❌ Menggabungkan Keprihatinan
Kesalahan yang sering terjadi adalah menggabungkan aturan bisnis dengan keterbatasan teknis dalam langkah yang sama. Sebagai contoh, mengatakan “Diberikan basis data terhubung” mencampurkan infrastruktur dengan perilaku. Sistem harus mengasumsikan koneksi diatur pada tingkat yang lebih rendah. Fokus pada konteks bisnis.
❌ Kata Kerja yang Tidak Jelas
Kata-kata seperti “proses”, “kelola”, atau “tangani” terlalu umum. Mereka tidak mendefinisikan hasilnya. Alih-alih mengatakan “Sistem memproses pesanan”, gunakan “Email konfirmasi pesanan dikirim”. Spesifisitas menghilangkan kesalahan interpretasi.
❌ Terlalu Banyak Skenario
Meskipun detail baik, terlalu banyak spesifikasi menciptakan beban pemeliharaan. Jika sebuah skenario memiliki dua puluh langkah Diberikan, kemungkinan besar sedang mencoba melakukan terlalu banyak hal. Pisahkan menjadi blok konteks yang lebih kecil dan dapat digunakan kembali.
❌ Keterikatan Teknis
Jangan menulis skenario yang bergantung pada detail implementasi tertentu seperti nama kelas atau skema basis data. Detail ini sering berubah dan menyebabkan uji coba gagal tanpa alasan. Fokus pada perilaku yang dapat diamati.
👥 Dinamika Kolaborasi
Kekuatan dari Diberikan Ketika Maka terletak pada kolaborasi yang dipupuk. Ini bukan hanya format dokumentasi; ini adalah alat fasilitasi untuk menyelaraskan tim.
- Pemilik Produk: Mereka menentukan hasil “Maka” berdasarkan nilai bisnis. Mereka memastikan perilaku memenuhi kebutuhan pengguna.
- Pengembang: Mereka menjelaskan konteks “Diberikan” untuk memahami prasyarat dan ketergantungan.
- Spesialis QA: Mereka memvalidasi tindakan “Ketika” untuk memastikan sistem merespons dengan benar dan kasus batas tercakup.
Pemahaman bersama ini mengurangi ketergantungan pada dokumentasi yang berada dalam isolasi. Ketika spesifikasi ditulis dalam format bersama, setiap orang berkontribusi terhadap kualitas persyaratan.
🔁 Dari Spesifikasi ke Otomatisasi
Salah satu keunggulan utama dari sintaks ini adalah pemetaan langsungnya ke kerangka kerja pengujian otomatis. Meskipun alat tertentu berbeda, struktur logisnya tetap konsisten.
Ketika sebuah skenario ditulis dengan jelas, dapat diterjemahkan ke dalam kode yang dapat dieksekusi dengan sedikit hambatan:
- Definisi Langkah:Setiap frasa Diberikan, Ketika, atau Maka dapat dipetakan ke fungsi dalam rangkaian pengujian.
- Dapat Digunakan Kembali:Konteks umum (seperti “Pengguna telah masuk”) dapat didefinisikan sekali dan digunakan kembali di berbagai skenario.
- Keamanan Regresi:Seiring aplikasi berkembang, skenario ini berfungsi sebagai jaring pengaman, memastikan kode baru tidak merusak perilaku yang sudah ada.
Integrasi ini menciptakan satu sumber kebenaran. Kriteria penerimaan adalah pengujian, dan pengujian adalah kriteria penerimaan. Keselarasan ini memastikan bahwa apa yang diuji adalah persis apa yang disepakati.
💎 Contoh Praktis
Untuk mengilustrasikan perbedaan antara persyaratan standar dan spesifikasi perilaku, mari kita lihat fitur tertentu: permintaan pengaturan ulang kata sandi.
❌ Spesifikasi yang Tidak Jelas
“Pengguna harus dapat mengatur ulang kata sandinya jika lupa. Sistem harus mengirim email.”
Ini meninggalkan terlalu banyak ruang untuk interpretasi. Apa yang terjadi jika alamat email tidak valid? Bagaimana jika pengguna tidak ada? Waktu pengiriman email tidak ditentukan.
✅ Diberikan Ketika Maka Spesifikasi
Skenario: Meminta Pengaturan Ulang Kata Sandi
Diberikanpengguna memiliki akun yang terdaftar dengan email “[email protected]”
Ketikamereka mengirimkan formulir pengaturan ulang dengan alamat email tersebut
Makapesan konfirmasi ditampilkan di layar
Dantautan pengaturan ulang dikirim ke “[email protected]”
Skenario: Mengatur Ulang dengan Email Tidak Dikenal
Diberikantidak ada akun yang terkait dengan “[email protected]”
Ketikamereka mengirimkan formulir pengaturan ulang
Makapesan sukses umum ditampilkan
Dantidak ada email yang dikirim ke alamat yang diberikan
Contoh-contoh ini menunjukkan bagaimana keamanan dan kenyamanan digunakan secara eksplisit. Skenario kedua melindungi privasi pengguna dengan tidak mengungkapkan apakah akun ada, pertimbangan keamanan yang sangat penting.
🛡️ Skenario Berbasis Data
Seringkali, satu perilaku berlaku untuk beberapa kumpulan data. Menulis skenario terpisah untuk setiap variasi bisa menjadi berulang. Solusinya adalah menggunakan Kerangka Skenario.
Struktur ini memungkinkan Anda mendefinisikan alur sekali dan mengisinya dengan titik data yang berbeda.
| Jumlah Masukan | Saldo yang Diharapkan | Status |
|---|---|---|
| $50 | $150 | Berhasil |
| $-10 | $100 | Kesalahan |
| $1000 | $1000 | Batas Tercapai |
Dengan mendefinisikan alur menggunakan tempat penampung, Anda mempertahankan keterbacaan sekaligus memastikan cakupan yang komprehensif. Pendekatan ini mengurangi duplikasi dan membuat pembaruan menjadi lebih mudah. Jika alur berubah, Anda memperbarui templat daripada lima puluh skenario individu.
📏 Pemeliharaan dan Evolusi
Spesifikasi bukanlah artefak statis. Mereka harus berkembang seiring matangnya produk. Tinjauan rutin diperlukan untuk memastikan langkah-langkah Given When Then tetap akurat.
Praktik terbaik untuk pemeliharaan meliputi:
- Refactoring Langkah-langkah: Jika suatu langkah menjadi terlalu kompleks, refaktorkan menjadi unit-unit kecil yang bermakna.
- Penghentian Penggunaan: Hapus skenario yang tidak lagi mencerminkan logika bisnis saat ini.
- Versi: Lacak perubahan pada skenario untuk memahami bagaimana kebutuhan berubah seiring waktu.
Menginvestasikan waktu dalam memelihara spesifikasi ini memberi manfaat berupa penurunan jumlah bug dan onboarding yang lebih cepat bagi anggota tim baru. Pengembang baru dapat membaca skenario untuk memahami perilaku sistem tanpa harus menyelami kode.
💡 Pikiran Akhir tentang Spesifikasi
Menulis spesifikasi yang jelas adalah disiplin yang membutuhkan latihan dan perhatian terhadap detail. Pola Given When Then menyediakan kerangka yang kuat untuk disiplin ini. Ini mendorong tim untuk memikirkan implikasi fitur mereka sebelum menulis kode.
Dengan fokus pada konteks, tindakan, dan hasil, Anda menciptakan dokumen hidup yang mendorong pengembangan dan pengujian. Ini menyelaraskan tim di sekitar definisi bersama tentang selesai. Keterpaduan ini adalah fondasi dari pengiriman perangkat lunak berkualitas tinggi.
Ingat bahwa tujuannya adalah komunikasi. Jika seorang pemangku kepentingan tidak dapat memahami skenario, maka skenario tersebut belum siap. Gunakan struktur ini untuk mendorong dialog, memperjelas ekspektasi, dan membangun perangkat lunak yang benar-benar memenuhi kebutuhan pengguna.
