Standar Kualitas Perangkat Lunak

1 Memahami tujuan bisnis.

Behaviour-Driven Development (BDD) adalah proses pengembangan perangkat lunak yang mengelola kepentingan bisnis sekaligus wawasan teknis. Pelanggan membicarakan bisnis dalam bentuk contoh skenario; ini merupakan cara yang efektif untuk mengartikulasikan kebutuhan bisnis, mengidentifikasi asumsi yang tidak valid, dan memastikan bahwa semua aspek telah tercakup. Hal ini, pada gilirannya, membantu menghindari cacat produk dan pengerjaan ulang di sepanjang sisa proses. Pakar pengalaman pengguna (UX) juga dapat dilibatkan pada tahap penemuan persyaratan untuk membantu memahami lebih baik para pengguna dari sistem masa depan tersebut.

2 Menentukan dan mengilustrasikan fitur.

Tim SA, DEV, dan QA menyampaikan persyaratan bisnis dalam bentuk fitur-fitur. Namun, mereka memberikan kepentingan khusus pada pemahaman (dan memastikan tim memahami) nilai bisnis serta motivasi di balik setiap fitur. Cerita skenario yang dijelaskan adalah cara yang menekankan pada persyaratan bisnis dan nilai yang akan diberikan, seperti berikut:

Fitur dalam format ini biasanya ditulis oleh BA melalui kolaborasi dengan pelanggan dan tim pengembang. Fitur tersebut kemudian akan dimasukkan ke dalam *product backlog* sebagai dokumentasi.

3 Menghitung Mundur dan Memahami Output

Hal yang paling utama adalah kami akan fokus pada bagaimana fitur tersebut seharusnya berfungsi pada akhirnya. Sebagai contoh, untuk mengajukan formulir permohonan cuti secara daring (*online*), output yang dihasilkan mungkin mencakup:

• Formulir permohonan dikirimkan ke departemen HR.
• Jumlah hari cuti dan jenis cuti juga akan dikirimkan ke Departemen HR/Pemimpin Tim melalui email.
• Jumlah hari cuti akan dikurangi dari kuota jenis cuti yang bersangkutan.

Berfokus pada output membantu memusatkan upaya untuk memastikan fitur tersebut berfungsi dengan semestinya. Proses ini memastikan bahwa perangkat lunak kami akan selalu memenuhi kondisi yang telah ditetapkan di awal fase.

4 Mengeksplorasi dan Memetakan Proses serta Alur Bisnis

Setelah output dipahami, tim sering kali menggunakan pemetaan cerita (*story mapping*), pemetaan proses, atau teknik serupa lainnya untuk memahami alur di dalam sistem. Hal ini membantu mengidentifikasi cara tercepat untuk mengirimkan fitur yang dapat digunakan dan juga memastikan tidak ada langkah yang terlupakan.

Alur sederhana untuk fitur pengajuan permohonan cuti secara daring mungkin terlihat seperti ini:

Setiap aktivitas dalam alur tersebut mengundang diskusi seputar variasi, alur alternatif, dan kasus-kasus ekstrem. Sebagai contoh, jika kita bertanya tentang aktivitas “periksa jenis cuti”, kita mungkin akan mengetahui bahwa pemeriksaan tersebut berkaitan dengan jenis karyawan dan terdapat berbagai jenis cuti terkait, seperti cuti hamil dan lainnya.

5 Menentukan Fitur dengan Bahasa Gherkin

Anggota tim yang akan mengerjakan fitur atau cerita tertentu berkumpul untuk mendiskusikan persyaratan secara mendetail. Hal ini biasanya melibatkan setidaknya perwakilan bisnis (BA), seorang pengembang, dan seorang penguji (*tester*). Tujuan dari sesi ini adalah agar anggota tim mendapatkan pemahaman mendalam tentang aturan bisnis dan kriteria penerimaan untuk fitur tersebut, serta secara aktif mengungkap kompleksitas atau risiko yang sebelumnya terlewatkan yang mungkin menghambat upaya pengembangan selanjutnya.

Tim sering kali menyampaikan kriteria penerimaan menggunakan format **“Given-When-Then”** yang sudah dikenal luas, seperti pada contoh berikut:

6 Pengujian Otomatis

Spesifikasi yang dapat dieksekusi kini siap untuk diuji. Pengujian otomatis ini dapat dilakukan oleh teknisi, pengembang, atau hasil kolaborasi antara keduanya. Dalam semua kasus, pekerjaan otomatisasi cenderung dimulai sedini mungkin pada fase pengembangan dan biasanya dilakukan secara paralel atau segera setelah pekerjaan pengembangan selesai.

7 Pengiriman

Tujuan dari praktik *Behaviour-Driven Development* (BDD) adalah untuk mengirimkan fitur yang lebih bernilai bagi bisnis dengan lebih cepat dan dalam ritme yang rutin. Dengan menggabungkan BDD dan kriteria penerimaan otomatis, tim dapat menunjukkan ketertelusuran yang jelas antara output yang dikirimkan (dan telah diuji keberhasilannya) dengan persyaratan yang didiskusikan pada awalnya.

8 Melengkapi Kriteria Penerimaan

Pengujian otomatis bersifat wajib untuk menunjukkan pemenuhan persyaratan dalam kriteria penerimaan. Dengan kata lain, pengembangan belum dianggap selesai sampai perangkat lunak diuji dan lulus kriteria penerimaan tersebut. Perencanaan dan pengujian berbasis tujuan yang jelas ini mengurangi jumlah cacat (*defect*) yang perlu diperbaiki setelah *sprint* selesai, sehingga pengembang dapat memfokuskan upaya mereka pada implementasi fitur-fitur baru.

9 Uji Regresi

Rangkaian uji regresi (*regression test suite*) adalah kumpulan pengujian yang dirancang untuk memastikan bahwa perangkat lunak tetap akurat dan benar setelah menjalani perbaikan maupun perubahan. Rangkaian uji regresi ini disusun berdasarkan fitur dan kapabilitas, yang kemudian dapat berfungsi sebagai bentuk dokumentasi fungsional; tidak hanya menjelaskan apa yang dilakukan sistem, tetapi juga tujuan bisnis apa yang ingin dicapai.