Cegah Bug Lolos dengan Empat Teknik Black-Box Testing

Berapa banyak test case yang telah disusun oleh tim QA Anda? Dari jumlah tersebut, berapa banyak yang benar-benar menguji kondisi paling kritis? Tim yang pernah menemukan bug setelah aplikasi dirilis tentu memahami bahwa banyaknya test case tidak selalu barbanding lurus dengan kualitas pengujian.

Pada setiap sprint, tim mungkin terus menambahkan skenario baru dengan harapan cakupan pengujian semakin luas. Sayangnya, tanpa teknik pengujian yang jelas, tester seringkali menguji fitur serupa secara berulang, sementara requirements lainnya justru belum tersentuh.

Laporan dari Consortium for Information & Software Quality (CISQ) tahun 2022 menyebutkan bahwa biaya akibat kualitas perangkat lunak yang buruk di Amerika Serikat mencapai sedikitnya USD 2,41 triliun. Angka ini memang tidak secara khusus disebabkan oleh kegagalan penyusunan test case, tetapi menunjukkan besarnya konsekuensi ekonomi yang dapat ditimbulkan.

Untuk menghindari pola tersebut, tim QA tidak cukup hanya memperbanyak test case. Tim perlu menyusun skenario pengujian menggunakan teknik yang sistematis agar setiap data, batas, aturan, dan perubahan perilaku sistem dapat diuji secara terarah.

Apa Itu Black-Box Testing?

Black-box testing merupakan teknik pengujian berbasis spesifikasi yang menganalisis perilaku sistem tanpa mengacu pada struktur internal (source code). Caranya adalah dengan memeriksa input, keluaran yang dihasilkan, dan respons sistem berdasarkan logika yang telah ditentukan dalam functional requirements atau non-functional requirements.

Kondisi pengujian, test case, dan data uji dapat diturunkan dari berbagai dasar pengujian, seperti dokumen kebutuhan (PRD, BRD, System Spec), use case, user story, dan Acceptance Criteria. Pendekatan ini membantu tim memeriksa apakah implementasi sistem sudah sesuai dengan requirements yang diharapkan.

Silabus ISTQB CTFL v4.0.1 menjelaskan bahwa test case masih dapat digunakan ketika implementasi berubah, selama requirements yang dipersyaratkan tetap sama. ISTQB juga membahas empat teknik black-box testing yang umum digunakan, yaitu equivalence partitioning, boundary value analysis, decision table testing, dan state transition testing.

Keempat teknik tersebut tidak saling menggantikan. Masing-masing digunakan untuk memeriksa jenis perilaku sistem dan menemukan jenis cacat yang berbeda.

Empat Teknik dalam Black-Box Testing

1. Equivalence Partitioning: Memilih Data yang Mewakili Setiap Kelompok

Equivalence partitioning membagi data uji ke dalam beberapa kelompok atau partisi yang diperkirakan akan diproses dengan cara yang sama oleh sistem. Penguji kemudian memilih satu atau beberapa nilai yang mewakili setiap partisi, baik partisi valid maupun tidak valid.

Sebagai contoh, apabila suatu kolom hanya menerima angka dari 1 hingga 100, data dapat dibagi menjadi tiga partisi, yaitu angka kurang dari 1, angka antara 1 dan 100, serta angka lebih dari 100. Penguji tidak perlu mencoba seluruh angka dalam rentang tersebut, tetapi cukup memilih nilai yang mewakili setiap partisi.

Partisi yang baik tidak saling tumpang tindih, tidak kosong, dan mencakup seluruh domain data yang relevan. Dengan pendekatan ini, jumlah test case dapat dikendalikan tanpa mengabaikan variasi perilaku sistem.

2. Boundary Value Analysis: Menguji Titik Rawan di Sekitar Batas

Boundary value analysis digunakan untuk menguji nilai yang berada tepat pada batas, tepat di bawah batas, dan tepat di atas batas. Teknik ini merupakan pengembangan dari equivalence partitioning dan diterapkan pada data yang memiliki urutan, seperti angka, tanggal, waktu, panjang karakter, ukuran berkas, atau jumlah barang.

Sebagai contoh, ketentuan menyatakan bahwa tenaga penjual memperoleh bonus apabila total penjualan tahunan mencapai sedikitnya 300.000. Nilai uji dapat disusun sebagai berikut:

Kondisi Pengujian	Nilai Uji	Hasil yang Diharapkan
Tepat di bawah batas	299.999	Tidak memperoleh bonus
Tepat pada batas	300.000	Memperoleh bonus
Tepat di atas batas	300.001	Memperoleh bonus

Apabila sistem hanya memeriksa kondisi nilai == 300.000, pengujian menggunakan nilai 300.001 akan mengungkap bahwa sistem tidak menerapkan ketentuan nilai >= 300.000 dengan benar.

Penerapan boundary value analysis membantu tim menemukan kesalahan pada batas minimum dan maksimum, mendeteksi penggunaan operator pembanding yang tidak tepat, serta memastikan nilai di dalam dan di luar batas diproses sesuai ketentuan.

3. Decision Table Testing: Memetakan Kombinasi Kondisi secara Sistematis

Decision table testing digunakan ketika keluaran atau tindakan sistem ditentukan oleh kombinasi beberapa kondisi. Teknik ini memetakan kondisi, aturan, dan tindakan ke dalam sebuah tabel sehingga setiap kombinasi yang relevan dapat diperiksa secara sistematis.

Sebagai contoh, pemberian diskon dapat dipengaruhi oleh status keanggotaan, jumlah transaksi, jenis produk, dan keberadaan kode promosi. Setiap kolom dalam tabel keputusan mewakili satu aturan, sedangkan setiap aturan menunjukkan kombinasi kondisi beserta tindakan yang harus dihasilkan.

Teknik ini membantu tim menemukan aturan bisnis yang belum memiliki hasil, keluaran yang saling bertentangan, kombinasi kondisi yang tidak mungkin terjadi, tindakan yang tidak sesuai, serta aturan yang belum memiliki test case. Karena itu, decision table testing cocok digunakan pada penentuan tarif, validasi hak akses, persetujuan berjenjang, kelayakan pengajuan, serta aturan transaksi dan pembayaran.

4. State Transition Testing: Mengungkap Cacat pada Perubahan Status

State transition testing digunakan untuk menguji perubahan keadaan atau status sistem ketika menerima peristiwa atau masukan tertentu. Teknik ini memetakan status yang dapat dimiliki sistem, peristiwa yang memicu perubahan, transisi yang diperbolehkan, serta transisi yang harus ditolak.

Pengujian dapat dirancang untuk mencakup setiap status, setiap transisi yang valid, urutan transisi tertentu, maupun transisi yang tidak valid. Misalnya, pesanan yang telah dibatalkan seharusnya tidak dapat langsung berubah menjadi selesai tanpa melalui proses yang diperbolehkan.

Teknik ini sesuai digunakan pada alur pesanan dan pengiriman, persetujuan dokumen, status pembayaran, penguncian akun, proses perizinan, aplikasi berbasis menu, serta sistem tertanam. Dengan menguji hubungan antarkondisi, tim dapat menemukan cacat yang tidak terlihat ketika setiap fungsi hanya diperiksa secara terpisah.

Apa yang Terjadi Jika Tim Menyusun Test Case Tanpa Teknik yang Tepat?

Tanpa teknik desain pengujian, setiap penguji dapat memilih data dan skenario berdasarkan intuisi masing-masing. Akibatnya, jumlah pengujian terus bertambah, tetapi cakupannya sulit diukur, dijelaskan, dan dipertanggungjawabkan.

Pertama, Data Uji Membengkak, tetapi Cakupannya Tidak Bertambah

Penguji sering menggunakan banyak data untuk menguji satu fungsi, padahal sebagian besar data tersebut diproses dengan cara yang sama oleh sistem. Pengujian menjadi panjang dan berulang tanpa menghasilkan temuan baru.

Contohnya:

• Kolom numerik diuji menggunakan puluhan angka yang sebenarnya memiliki perilaku setara
• Nilai kosong, negatif, atau di luar rentang justru tidak pernah diuji
• Data yang telah diuji pada iterasi sebelumnya digunakan kembali tanpa alasan yang jelas

Jumlah data yang banyak tidak selalu menghasilkan pengujian yang lebih tajam. Tim perlu mengelompokkan data berdasarkan fungsi sistem, kemudian memilih nilai yang dapat mewakili setiap kelompok.

Kedua, Bug Lolos ke Production

Kesalahan logika sering muncul di sekitar nilai minimum dan maksimum. Perbedaan penggunaan operator < dan <=, misalnya, dapat menyebabkan sistem memberikan hasil yang salah hanya pada nilai tertentu.

Contohnya:

• Pengguna berusia tepat 18 tahun masih dianggap belum memenuhi batas usia
• Diskon tidak diberikan ketika nilai transaksi tepat mencapai batas minimum
• Sistem tanggal gagal memproses hari pertama atau hari terakhir dalam suatu bulan
• Berkas dengan ukuran tepat pada batas maksimum justru ditolak

Pengujian menggunakan nilai tengah saja tidak cukup. Tim perlu memberikan perhatian khusus pada batas nilai yang, sedikit di bawah batas, dan sedikit di atas batas.

Ketiga, Requirements yang Kompleks Tidak Diuji secara Lengkap

Sebuah fungsi dapat dipengaruhi oleh beberapa kondisi sekaligus. Tanpa pemetaan yang sistematis, penguji biasanya hanya memeriksa kombinasi yang paling umum atau mudah dipahami.

Contohnya:

• Diskon ditentukan berdasarkan status keanggotaan, nilai transaksi, jenis produk, dan kode promosi
• Persetujuan pembayaran bergantung pada nominal transaksi, jabatan pemberi persetujuan, dan ketersediaan anggaran
• Hak akses dokumen dipengaruhi oleh peran pengguna, unit kerja, status akun, dan tingkat kerahasiaan
• Biaya pengiriman ditentukan berdasarkan wilayah, berat barang, metode pengiriman, dan jenis pelanggan

Aturan bisnis yang melibatkan banyak kondisi perlu dipetakan secara terstruktur agar setiap kombinasi yang relevan dapat diperiksa dan memiliki test case yang jelas.

Keempat, Perubahan Status Sistem Tidak Diuji secara Menyeluruh

Beberapa aplikasi memberikan respons berdasarkan status sistem sebelumnya. Dalam kondisi ini, menguji setiap fungsi secara terpisah belum tentu cukup karena sistem juga harus memproses perpindahan antarkondisi secara benar.

Contohnya:

• Pesanan berpindah dari status dibuat, diproses, dikirim, hingga selesai
• Dokumen berubah dari status draf, diajukan, diperiksa, disetujui, atau ditolak
• Akun berubah dari aktif menjadi terkunci setelah beberapa kali gagal masuk
• Permohonan yang telah dibatalkan tidak boleh langsung dikembalikan menjadi disetujui

Pengujian perlu mencakup status awal, peristiwa pemicu, status tujuan, serta perpindahan yang harus ditolak agar seluruh alur sistem dapat diperiksa secara menyeluruh.

Keempat masalah tersebut memiliki akar yang sama, yaitu test case disusun sebelum tim menentukan model dan teknik pengujian yang tepat. Solusinya dapat dimulai dengan menerapkan empat teknik utama dalam black-box testing.

Tingkatkan Ketajaman Test Case Tim QA

Tim QA tidak kekurangan test case. Masalah sering muncul karena skenario pengujian tidak diturunkan melalui teknik yang tepat. Tanpa teknik desain pengujian, data uji dapat terus bertambah, tetapi bagian kritis tetap terlewat. Cacat pada batas minimum dan maksimum dapat lolos ke production, kombinasi aturan bisnis tidak diuji secara lengkap, dan perpindahan status yang tidak valid tidak terdeteksi.

Empat teknik black-box testing membantu menutup celah tersebut. Equivalence partitioning mengelompokkan data ke dalam partisi yang setara, boundary value analysis memusatkan pengujian pada batas input, decision table testing memetakan kombinasi kondisi dan aturan bisnis, sedangkan state transition testing menguji perubahan status serta urutan proses.

Jika Brainers ingin menyusun test case secara lebih sistematis, terukur, dan sesuai dengan kebutuhan pengembangan perangkat lunak, ikuti course Software Testing Fundamentals dari Brainmatics.

Dalam course ini, Brainers akan mempelajari:

• Konsep dan prinsip dasar pengujian perangkat lunak
• Analisis dan desain pengujian
• Equivalence partitioning
• Boundary value analysis
• Decision table testing
• State transition testing
• Pengelolaan dan dokumentasi test case
• Studi kasus serta latihan pengujian perangkat lunak

Hubungi Learning Advisor Brainmatics untuk berkonsultasi mengenai jadwal, metode pelaksanaan, dan detail course.

Sumber Data dan Referensi

International Software Testing Qualifications Board. 2024. Certified Tester Foundation Level Syllabus v4.0.1,
ISO/IEC/IEEE. 2021. ISO/IEC/IEEE 29119-4:2021 Software and Systems Engineering
Krasner, Herb. 2022. The Cost of Poor Software Quality in the US: A 2022 Report. Consortium for Information & Software Quality.