Decision table

Ketika beberapa kondisi bergabung menghasilkan output berbeda, sebuah tabel menemukan aturan yang tidak ditulis siapa pun.

Kapan menjangkaunya

Partitioning dan BVA menangani satu input dalam satu waktu. Decision table (tabel keputusan) menangani kombinasi: "gratis ongkir kalau pesanan di atas Rp 500.000 dan alamatnya domestik, kecuali pelanggannya member, yang dalam hal itu…".

Prosa menyembunyikan celah pada aturan semacam itu. Sebuah tabel membuatnya mustahil disembunyikan — dan karena itulah nilai sesungguhnya teknik ini sering ditemukan sebelum Anda menjalankan apa pun: Anda mengisi tabelnya, tiga sel tidak punya jawaban yang terdefinisi, lalu Anda pergi bertanya.

Membangunnya, langkah demi langkah

Kebutuhan. Checkout ShopMini: pelanggan mendapat gratis ongkir kalau total pesanan di atas Rp 500.000. Member selalu mendapat gratis ongkir. Pesanan ke alamat internasional tidak pernah mendapat gratis ongkir.

Langkah 1 — daftar kondisinya (inputnya, dibuat ya/tidak sebisa mungkin):

C1: total di atas Rp 500.000?
C2: pelanggan adalah member?
C3: alamat internasional?

Langkah 2 — daftar aksinya (output-nya):

A1: gratis ongkir
A2: bebankan ongkir Rp 20.000

Langkah 3 — daftar seluruh kombinasinya. Tiga kondisi biner → 2³ = 8 aturan.

	R1	R2	R3	R4	R5	R6	R7	R8
C1 di atas 500rb	Y	Y	Y	Y	N	N	N	N
C2 member	Y	Y	N	N	Y	Y	N	N
C3 internasional	Y	N	Y	N	Y	N	Y	N
A1 gratis ongkir	?	✓	✗	✓	?	✓	✗	✗
A2 bebankan 20rb	?		✓		?		✓	✓

Langkah 4 — isi aksinya, dan tandai yang tidak bisa Anda isi. R1 dan R5 adalah tanda tanya: seorang member dengan alamat internasional. "Member selalu mendapat gratis ongkir" dan "internasional tidak pernah mendapat gratis ongkir" saling bertentangan. Kebutuhannya tidak menyebutkan mana yang menang.

Itulah output-nya. Sebelum menulis satu pengujian pun Anda sudah menemukan cacat sungguhan di spesifikasi — jenis yang tiga bulan kemudian terkirim sebagai perdebatan antara support dan keuangan. Bawa R1 dan R5 ke product owner.

Langkah 5 — satu test case per aturan. Delapan kolom, delapan pengujian, masing-masing dengan data konkret.

Meringkas tabelnya

2ⁿ tumbuh cepat: enam kondisi berarti 64 aturan. Ada dua cara sah untuk mengecilkannya:

Tanda hubung untuk kondisi yang tidak relevan. Kalau internasional selalu berarti ongkir dibayar terlepas dari yang lain, R3 dan R7 melebur jadi satu aturan dengan C1 dan C2 diisi "–" (tidak peduli). Lebih sedikit pengujian, cakupan output yang sama.

Uji aksi yang berbeda, bukan setiap kombinasi. Kalau delapan aturan hanya menghasilkan dua output berbeda, prioritaskan setidaknya satu pengujian per output, ditambah kombinasi yang melibatkan kondisi paling licin.

Hati-hati: meringkas mengandaikan Anda sudah tahu kondisi-kondisinya saling bebas. Andaian itu justru yang ingin diperiksa oleh decision table, jadi ringkas setelah Anda mendaftar semuanya, bukan sebagai gantinya.

Cakupan, dinyatakan terus terang

Cakupan minimum decision table = satu pengujian per aturan (per kolom). Kalau ada yang bertanya "dari mana Anda tahu logika harga ini sudah tercakup?", tabelnya adalah jawabannya, dan itu jawaban yang jauh lebih baik daripada sebuah angka.

Contoh kedua, yang lebih licik

Login: sebuah akun bisa belum terverifikasi, aktif, atau terkunci. Kata sandinya bisa benar atau salah. 2FA bisa aktif atau tidak.

3 × 2 × 2 = 12 aturan. Sekarang coba jawab dari kebutuhannya: apa yang terjadi kalau akun terkunci memasukkan kata sandi benar dengan 2FA aktif? Haruskah pesan kesalahannya mengungkap bahwa akun itu terkunci (membantu) atau tetap umum (aman)? Tidak ada yang menuliskannya. Tabelnya yang menemukannya.

🛠 Giliran Anda, di TestForge

Latihan sandbox meminta Anda membangun tabel ongkir ShopMini sebagai satu suite test case — satu case per aturan, dinamai supaya pembaca tahu aturan mana yang dicakupnya, dengan aturan yang bertentangan diangkat sebagai pertanyaan alih-alih ditebak-tebak.

Checker-nya menghargai dua hal: cakupan aturan yang penuh, dan tidak diam-diam mengarang jawaban untuk R1/R5.

Periksa pemahaman Anda

Empat kondisi biner. Berapa aturan sebelum diringkas?
Apa yang Anda lakukan pada sel yang output-nya tidak didefinisikan kebutuhannya?
Kenapa "kami sudah menguji kombinasi utamanya" adalah jawaban yang lebih lemah daripada sebuah decision table?

Selanjutnya: state transition testing, untuk perilaku yang bergantung pada apa yang terjadi sebelumnya.