Decision Table Testing: Biến Business Rule phức tạp thành Test Case có hệ thống

Một business rule chỉ có một điều kiện thường không quá khó để test.

Nhưng khi requirement bắt đầu xuất hiện những câu như:

• Nếu số lượng từ 1–3 thì tính giá này.
• Nếu từ 4–6 thì tính giá khác.
• Nếu vượt quá 6 sản phẩm thì cần thêm túi.
• Phí vận chuyển lại phụ thuộc vào tổng trọng lượng.
• Tổng trọng lượng còn phải cộng thêm trọng lượng của túi.
• Ngoài ra còn có một khoản phí cố định cho mỗi shipment.

thì số lượng trường hợp cần kiểm tra bắt đầu tăng rất nhanh.

Nếu Tester chỉ brainstorm testcase dựa trên cảm giác, rất dễ xảy ra hai vấn đề:

Bỏ sót một combination quan trọng hoặc viết nhiều testcase nhưng thực tế lại kiểm tra cùng một business rule.

Đây là lúc Decision Table trở nên hữu ích.

Decision Table giúp chuyển một requirement có nhiều điều kiện thành một bảng gồm:

Conditions → Rules → Expected Outcomes

Nói đơn giản:

Decision Table là cách đưa business rule vào bảng để nhìn rõ: với mỗi điều kiện khác nhau, hệ thống phải trả ra kết quả gì.

Từ đó Tester có thể nhìn rõ từng trường hợp business khác nhau trước khi bắt đầu viết testcase.

---

A. Khi business rule có quá nhiều “nếu” - Requirement có quá nhiều điều kiện

Khi một chức năng chỉ có một rule, việc test khá đơn giản.

Ví dụ:

Nếu user nhập sai password thì hiển thị error.

Nhưng nếu kết quả phụ thuộc vào nhiều thứ cùng lúc, việc test sẽ phức tạp hơn.

Ví dụ phí vận chuyển có thể phụ thuộc vào:

• số lượng item
• tổng trọng lượng
• số túi cần dùng
• phí cộng thêm

Nếu không tách rõ từng rule, Tester rất dễ rơi vào kiểu:

“Mình nghĩ đã test đủ rồi.”

Nhưng thực tế vẫn có thể thiếu một case quan trọng

---

Hãy lấy một task thực tế về tính phí vận chuyển.

Requirement ban đầu như sau:

1. Packing fee

Phí đóng gói được tính theo số lượng item:

• 1–3 items: $8
• 4–6 items: $15
• 7–9 items: $22

Có thể hiểu rule dưới dạng:

First 3 items = $8
Each additional 3 items = +$7

Ví dụ:

2 items → $8

5 items → $15

7 items → $22

2. Shipping fee theo trọng lượng

Bảng phí cộng thêm buffer được đề xuất:

Tổng trọng lượng	Shipping fee
< 1.000 kg	$32
1.000–1.499 kg	$39
1.500–1.999 kg	$46
2.000–2.499 kg	$53
2.500–5.999 kg	$60

Ngoài ra:

• mỗi shipment bag nặng 30g
• nếu nhiều hơn 6 balls thì cần thêm bag
• mỗi shipment cộng thêm $2 (để dự phòng các trường hợp shipment gặp vấn đề, bị return hoặc phải gửi lại.)

Đến đây, việc tính phí không còn đơn giản là:

Quantity × Price

mà đã trở thành sự kết hợp của nhiều business rules.

---

Một ví dụ cụ thể

Giả sử Parent đặt:

3 × Size 4 ball
2 × 110g bib
1 × L bib
1 × XL bib

Tổng cộng:

7 items

Tính packing fee

7 items thuộc khoảng 7–9 items.

Vì vậy:

Packing fee = $22

Tính trọng lượng sản phẩm

Giả sử:

3 balls × 315g = 945g

2 bibs × 110g = 220g

1 L bib = 160g

1 XL bib = 160g

Tổng trọng lượng sản phẩm:

945 + 220 + 160 + 160
= 1,485g

Cộng thêm một shipment bag:

1,485g + 30g
= 1,515g
= 1.515kg

1.515kg nằm trong khoảng:

1.500–1.999kg

Theo bảng phí mới:

Shipping by weight = $46

Nếu áp dụng thêm phí cố định $2 cho shipment:

Packing fee       = $22
Weight fee        = $46
Shipment buffer   = $2
-----------------------
Total             = $70

Nhìn một ví dụ thì logic có vẻ khá dễ hiểu.

Nhưng với Tester, câu hỏi quan trọng hơn là:

Chúng ta đã kiểm tra hết các trường hợp có thể làm kết quả thay đổi chưa?

---

B. Decision Table giúp gì cho Tester? Các bước tạo ra 1 Decision Table

Decision Table giúp Tester trả lời 3 câu hỏi:

1. Điều kiện nào ảnh hưởng đến kết quả?

2. Với mỗi điều kiện, expected result là gì?

3. Có trường hợp nào requirement chưa nói rõ không?

Thay vì giữ mọi thứ trong đầu, chúng ta đưa chúng ra bảng.

Bước 1: Tách requirement thành Conditions

Đừng bắt đầu bằng việc viết testcase.

Trước tiên, hãy liệt kê những điều kiện có thể làm thay đổi kết quả.

Trong task này, có thể bắt đầu với:

Condition 1: Tổng số item

Packing fee phụ thuộc vào số lượng:

Số item
Packing fee
1–3
$8
4–6
$15
7–9
$22

Condition 2: Tổng trọng lượng sau khi cộng bag

Shipping fee phụ thuộc vào:

< 1kg

1.000–1.499kg

1.500–1.999kg

2.000–2.499kg

2.500–5.999kg

Condition 3: Số lượng shipment bag

Bag có trọng lượng 30g.

Theo requirement hiện có:

≤ 6 balls → 1 bag

> 6 balls → cần thêm bag

Condition 4: Shipment fee cố định

Mỗi shipment cộng thêm:

$2

Chỉ riêng bốn nhóm condition này đã tạo ra khá nhiều trường hợp có thể xảy ra.

---

Bước 2: Xác định Actions hoặc Outcomes

Sau khi có Conditions, tiếp theo cần xác định kết quả mà hệ thống phải tạo ra.

Trong ví dụ này, các outcome quan trọng gồm:

• Packing fee.
• Number of shipment bags.
• Total shipment weight.
• Weight-based shipping fee.
• Additional shipment fee.
• Final shipping charge.

Điểm quan trọng là outcome phải là thứ Tester có thể quan sát hoặc kiểm tra được.

Ví dụ:

Packing fee = $22

là một outcome.

Trong khi:

Order contains 7 items

là condition hoặc input, không phải outcome.

Việc tách rõ hai nhóm này giúp Decision Table dễ đọc hơn rất nhiều.

---

Bước 3: Tạo các Rule có ý nghĩa và kết hợp các rules

Bước 3a: Tạo từng Rule rõ ràng

Bây giờ có thể bắt đầu chuyển requirement thành Decision Table. Trong đó, mỗi rule có thể hiểu là:

Nếu condition như thế này, thì expected result phải như thế kia.

Ví dụ đơn giản cho packing fee:

Rule	Số item	Packing fee
R1	1–3	$8
R2	4–6	$15
R3	7–9	$22

Chỉ riêng bảng này đã cho Tester thấy ngay các boundary quan trọng:

3 → 4 items
6 → 7 items

Đây thường là những điểm nên được ưu tiên test.

Ví dụ testcase có thể là:

3 items → $8

4 items → $15

6 items → $15

7 items → $22

Không cần test mọi con số từ 1 đến 9 nếu chúng đều nằm trong cùng một business rule.

Tương tự, chúng ta có thể chuyển bảng shipping thành:

Rule	Shipment weight	Weight fee
R1	< 1.000kg	$32
R2	1.000–1.499kg	$39
R3	1.500–1.999kg	$46
R4	2.000–2.499kg	$53
R5	2.500–5.999kg	$60

Điểm đáng chú ý không chỉ là các khoảng giá.

Tester cần tập trung vào boundary giữa hai rule.

Ví dụ:

0.999kg → $32

1.000kg → $39

hoặc:

1.499kg → $39

1.500kg → $46

Nếu chỉ test:

1.2kg
1.7kg

cả hai testcase đều có thể pass nhưng bug ở boundary vẫn bị bỏ sót.

Decision Table giúp những boundary này hiện ra rõ hơn ngay từ lúc thiết kế test.

Bước 3b: Khi nhiều rule kết hợp với nhau

Đây là phần thường làm requirement trở nên khó

Chẳng hạn:

• packing fee phụ thuộc số item
• shipping fee phụ thuộc weight
• weight lại phải cộng thêm trọng lượng bag

Vậy chỉ cần thay đổi một chi tiết nhỏ cũng có thể làm fee đổi.

Ví dụ:

Rule	Item count	Product weight	Bag	Final weight	Packing fee	Weight fee
R1	3	900g	30g	930g	$8	$32
R2	4	970g	30g	1,000g	$15	$39
R3	6	1,450g	30g	1,480g	$15	$39
R4	7	1,485g	30g	1,515g	$22	$46

Ở đây có một điểm rất dễ bị bỏ qua.

Giả sử shipment có tổng trọng lượng sản phẩm là:

970g

Nếu chưa cộng bag:

970g < 1kg

thì shipping fee là:

$32

Nhưng mỗi bag nặng 30g.

Vậy total weight thực tế là:

970g + 30g = 1000g

Lúc này shipment chuyển sang mức:

1.000–1.499kg

Shipping fee phải là:

$39

Chỉ một chi tiết nhỏ là bag weight đã làm fee đổi từ $32 sang $39.

Đây chính là loại case rất dễ bị bỏ sót nếu Tester chỉ viết testcase theo flow mà không tách business rule trước.

Bước 3c: Decision Table giúp phát hiện requirement chưa rõ

Một trong những lợi ích lớn nhất của Decision Table không phải là tạo testcase.

Mà là phát hiện câu hỏi cần hỏi lại BA, PO hoặc client trước khi Developer code sai logic.

Trong task này có một ví dụ khá rõ.

Requirement nói:

Each shipment bag is 30g and can fit up to 6 balls and bibs.

Nhưng sau đó lại nói:

If 1 order more than 6 balls, then we have to calculate an additional bag.

Vậy nếu order có:

3 balls + 7 bibs

thì dùng bao nhiêu bag?

Một bag vì chỉ có 3 balls?

Hay hai bag vì tổng cộng có 10 items?

Hoặc bag capacity phải tính theo kích thước thực tế của từng loại sản phẩm?

Requirement hiện tại chưa trả lời hoàn toàn rõ câu hỏi đó.

Tester không nên tự đoán.

Decision Table có thể làm lộ ngay khoảng trống này:

Balls	Bibs	Total items	Number of bags
3	3	6	1
6	0	6	1
7	0	7	2
3	7	10	?

Dấu ? chính là một missing requirement.

Thay vì đợi đến lúc test mới phát hiện, Tester có thể hỏi lại ngay:

Với 3 balls và 7 bibs thì hệ thống nên sử dụng một hay hai shipment bags?

Đây là một ví dụ rất điển hình cho việc Decision Table hỗ trợ requirement review.

---

Bước 4: Loại bỏ combination không cần thiết

Một sai lầm thường gặp khi dùng Decision Table là cố tạo mọi permutation có thể.

Ví dụ chúng ta có:

3 mức packing fee
5 mức weight fee
2 trạng thái bag

Nếu nhân tất cả với nhau sẽ có rất nhiều combination.

Nhưng không phải combination nào cũng cần một testcase riêng.

Ví dụ:

1 item + 1.2kg
2 items + 1.2kg
3 items + 1.2kg

Nếu cả ba đều:

• thuộc cùng packing tier;
• dùng cùng số bag;
• thuộc cùng weight tier;

thì business outcome không thay đổi.

Tester có thể chọn một trường hợp đại diện để test thay vì test cả ba.

Mục tiêu của Decision Table không phải là:

Tạo càng nhiều testcase càng tốt.

Mà là:

Tạo đủ testcase để mỗi business rule khác biệt đều được kiểm tra.

---

Bước 5: Từ Decision Table sang Test Case

Sau khi Decision Table được review và business rule đã rõ, mỗi rule có thể được chuyển thành testcase.

Ví dụ:

Test Case: 7 items với tổng shipment weight 1.515kg

Precondition

Shipping fee configuration:

1.500–1.999kg = $46

Packing rule:

7–9 items = $22

Shipment fee:

$2

Input

3 × Size 4 ball = 945g

2 × 110g bib = 220g

1 × L bib = 160g

1 × XL bib = 160g

1 shipment bag = 30g

Expected

Total items = 7

Packing fee = $22

Product weight = 1,485g

Shipment weight = 1,515g

Weight fee = $46

Additional shipment fee = $2

Final fee = $70

Như vậy testcase không còn được tạo ra bằng cảm giác. Nó được map trực tiếp từ một business rule đã được xác nhận.

Đặc biệt chú ý Boundary Cases

Decision Table và Boundary Value Analysis thường đi cùng nhau rất tốt. Chúng thường có khả năng xuất hiện bug cao hơn những giá trị nằm giữa khoảng. Vì 1 điều kiện nhỏ thay đổi cũng có thể kéo theo Boundary thay đổi, từ đó dẫn dến output cũng thay đổi theo. Nếu không chú ý thì rất dễ bỏ sót và gây ra lỗi.

Một lợi ích lớn khác khi có Decision: Dễ dàng Review requirement với BA, PO hoặc Client

Requirement dạng chat thường rất phổ biến trong dự án thực tế.

Ví dụ:

First 3 pieces = $8
Then every additional 3 pieces = $7

Người đọc có thể cảm thấy mình đã hiểu.

Nhưng Decision Table buộc chúng ta phải chuyển câu đó thành:

1 item → ?

2 items → ?

3 items → ?

4 items → ?

6 items → ?

7 items → ?

Ngay lập tức business logic trở nên cụ thể hơn.

Tương tự, thay vì hỏi:

“Logic shipment bag có đúng không?”

Tester có thể hỏi:

“Nếu có 7 balls thì mình hiểu là 2 bags. Nhưng nếu có 3 balls và 7 bibs thì vẫn 1 bag hay cần thêm bag?”

Câu hỏi thứ hai dễ trả lời hơn rất nhiều.

Decision Table biến một cuộc trao đổi mơ hồ thành một combination cụ thể cần quyết định.

---

C. Những sai lầm thường gặp khi sử dụng Decision Table

1. Condition quá chi tiết

Không phải field nào trên UI cũng cần trở thành một condition.

Ví dụ:

Parent first name
Parent last name
Email
Phone

không liên quan đến shipping fee thì không nên đưa vào table.

Chỉ giữ những condition có khả năng làm outcome thay đổi.

---

2. Trộn Condition và Outcome

Ví dụ:

Shipping fee = $46?

không phải condition.

Đó là expected outcome.

Condition nên là:

Shipment weight = 1.500–1.999kg

Sau đó outcome mới là:

Shipping fee = $46

---

3. Không test boundary

Chỉ test:

1.2kg
1.7kg
2.2kg

chưa đủ.

Các giá trị:

0.999kg
1.000kg
1.499kg
1.500kg

thường quan trọng hơn.

---

4. Không có rule cho trường hợp ngoài bảng

Ví dụ bảng fee hiện chỉ được định nghĩa đến:

5.999kg

Vậy nếu shipment là:

6.000kg

thì sao?

Reject order?

Chia shipment?

Có bảng giá khác?

Hiển thị contact support?

Nếu requirement chưa có câu trả lời thì đây là một missing rule cần được xác nhận.

---

5. Tester tự suy luận business rule

Ví dụ requirement chưa rõ:

3 balls + 7 bibs

cần bao nhiêu bag.

Tester không nên tự chọn một kết quả rồi viết testcase theo kết quả đó.

Một trong những nhiệm vụ quan trọng của test design là phát hiện phần chưa rõ và đưa nó quay lại cho business xác nhận.

---

D. Checklist khi thiết kế Decision Table

Trước khi chuyển Decision Table thành testcase, có thể kiểm tra nhanh:

• Các condition có thực sự làm thay đổi outcome không?
• Có condition nào nên chia thành các khoảng thay vì Yes/No không?
• Các boundary đã được xác định chưa?
• Có combination nào không thể xảy ra không?
• Có combination nào chưa có expected result không?
• Có hai rule nào cùng match nhưng cho outcome khác nhau không?
• Có default rule cho những input ngoài phạm vi không?
• Trọng lượng bag đã được tính trước khi chọn weight tier chưa?
• Rule thêm bag đã được định nghĩa rõ chưa?
• Khoản phí cố định $2 được tính theo order, shipment hay từng bag?
• Mỗi business outcome có ít nhất một testcase đại diện không?
• Các rule có thể map thành testcase rõ ràng không?

Nếu một ô trong Decision Table vẫn phải ghi ?, có thể Tester chưa cần viết testcase ngay.

Trước tiên cần làm rõ requirement.

---

Takeaway

Decision Table nghe có vẻ khá “học thuật”, nhưng cách dùng thực tế lại rất đơn giản.

Nó giúp Tester biến requirement kiểu:

“Nếu A thì thế này, nhưng nếu B thì thế kia, còn nếu C thì…”

thành một bảng rõ ràng.

Từ đó Tester có thể dễ dàng thấy:

• condition nào quan trọng
• outcome nào phải kiểm tra
• boundary nằm ở đâu
• case nào có thể bỏ
• requirement nào đang thiếu

Với ví dụ shipping fee ở trên, nếu chỉ nhìn từng requirement riêng lẻ thì logic có vẻ khá đơn giản:

Packing fee theo quantity

+

Shipping fee theo weight

+

Bag weight

+

Additional shipment fee

Nhưng khi những rule đó kết hợp với nhau, rất nhiều case mới xuất hiện:

• 3 items và 4 items.
• 6 items và 7 items.
• 0.999kg và 1.000kg.
• 1.499kg và 1.500kg.
• Một bag và hai bags.
• Trọng lượng sản phẩm dưới boundary nhưng sau khi cộng bag lại vượt boundary.
• Order có combination sản phẩm mà requirement chưa nói rõ cách chia bag.

Decision Table giúp Tester nhìn những trường hợp đó trước khi bắt đầu execute testcase.

Vì vậy, đây không chỉ là một kỹ thuật để viết test.

Nó còn là công cụ giúp Tester:

hiểu business rule → phát hiện missing requirement → xác định boundary → loại bỏ testcase dư thừa → chuyển logic thành testcase có hệ thống.

Một Decision Table tốt không nhất thiết phải rất lớn.

Nó chỉ cần giúp team trả lời rõ một câu hỏi:

Với combination điều kiện này, hệ thống chính xác phải làm gì?