Xin chào các bạn!
Mình là Bảo đến từ team QA của công ty Japan Quality.
Như các bạn đã biết, "Phân tích giá trị biên" và "Phân vùng tương đương" là những kỹ thuật test rất hữu ích, đặc biệt khi sử dụng để test các input field của UI. Tuy nhiên, thực tế có nhiều trường hợp cần phải kiểm tra cả những business logic ở bên dưới giao diện người dùng. Lần này, mình xin giới thiệu kỹ thuật "Decision Table (Bảng quyết định)", thường được sử dụng để kiểm tra business logic và cách kết hợp nó cùng với 2 kỹ thuật Phân vùng tương đương và Phân tích giá trị biên để tạo ra các testcase hiệu quả hơn nữa nhé.
1. Decision Table là gì?
Decision Table hay còn được gọi là Bảng quyết định, là bảng mô tả tóm tắt cách hệ thống hoạt động (output) ứng với các điều kiện đầu vào (input) khác nhau.
Trong trường hợp hệ thống có logic phức tạp (nhiều input và output, với mỗi bộ input khác nhau thì kết quả output cũng khác nhau) thì Dev/Tester sẽ rất dễ bị sót một số trường hợp cần xử lý/kiểm tra. Decision Table mô tả các business logic phức tạp dưới dạng dễ đọc và dễ kiểm soát, nhờ đó chúng ta có thể hệ thống hóa các pattern, giúp đảm bảo testcase cover toàn bộ các case cần test và dễ dàng hơn trong việc đọc hiểu requirement.
Một Decision Table thường có cấu trúc như bên dưới.
Các điều kiện được liệt kê ở trên cùng bên trái của bảng và các hoạt động ở dưới cùng bên trái. Mỗi cột ở bên phải tương ứng với một business rule. Mỗi rule cho biết “Dưới sự kết hợp các điều kiện cụ thể này (được hiển thị ở phần trên của rule), kết quả hệ thống sẽ thực hiện những hoạt động cụ thể này (được hiển thị ở phần dưới của rule)”.
2. Cách tạo Decision Table
Chúng ta hãy thử tạo một Decision table từ requirement sau nhé:
Khi user chọn thanh toán bằng thẻ tín dụng, các xử lý validation sau sẽ được thực hiện:
・Kiểm tra thông tin thẻ user đã nhập (Cardholder/Card number/CSC) có đúng không? Nếu NG thì không approve cho giao dịch đó và gọi điện đến Vendor
・Kiểm tra thẻ có đang hoạt động hay đã bị hủy? Nếu NG thì không approve cho giao dịch đó và gọi điện đến Vendor
・Kiểm tra số tiền thanh toán có nằm trong hoặc vượt quá limit của thẻ? Nếu NG thì không approve cho giao dịch đó và gọi điện đến Cardholder
・Kiểm tra giao dịch đến từ một địa điểm bình thường hay một địa điểm đáng ngờ? Nếu NG thì không approve cho giao dịch đó và gọi điện đến Cardholder
・Nếu tất cả các validation trên đều OK thì approve cho giao dịch đó
Step1：Phân tích yêu cầu và liệt kê ra các “Điều kiện (input)” và “Hoạt động (output)” của chức năng
Từ yêu cầu trên, chúng ta có thể liệt kê ra được 4 điều kiện input sau:
・Real account?
・Active account?
・Within limit?
・Location okay?
Và 3 hoạt động (kết quả) output như bên dưới:
・Approve?
・Call vendor?
・Call cardholder?
Step2：Điền “Điều kiện (input)” và “Hoạt động (output)” vào bảng
Step3：Điền toàn bộ kết hợp của các điều kiện vào bảng
Thông thường, số lượng cột (cũng là số lượng rule) trong phần chỉ định điều kiện sẽ là lũy thừa của 2. Nếu có 2 điều kiện thì có 4 cột, nếu có 3 điều kiện thì có 8 cột, nếu có 4 điều kiện thì có 2^4 = 16 cột.
Điền "Y" cho trường hợp thỏa điều kiện và "N" nếu không. Điểm chúng ta cần cẩn thận ở đây là cần phải liệt kê ra tất cả các tổ hợp của "Y" và "N". Nếu sót tổ hợp thì sẽ không đảm bảo được độ bao phủ của testcase. Vậy làm thế nào để có thể điền các tổ hợp vào bảng mà không bị sót?
Hãy cùng xem phần chỉ định điều kiện ở bảng trên. Điều kiện ở hàng trên cùng thay đổi chậm nhất. Một nửa số cột là “Y” và nửa còn lại là “N”. Hàng thứ hai thay đổi nhanh hơn một chút so với hàng đầu tiên, nhưng vẫn chậm hơn tất cả những hàng khác, pattern sẽ là: 4 cột “Y”, sau đó là 4 “N”, tiếp tục 4 “Y”, rồi 4 “N”. Cứ tương tự như vậy ở hàng tiếp theo. Cuối cùng, hàng dưới cùng thay đổi nhanh nhất theo pattern: “Y”, “N”, “Y”, “N”, “Y”,…Nếu các bạn tuân theo quy tắc chỉ định như trên thì sẽ không bị sót tổ hợp khi điền vào bảng.
Step4：Dựa trên phân tích yêu cầu, điền kết quả hoạt động output tương ứng với tổ hợp của các điều kiện input
Điền "X" cho trường hợp thỏa điều kiện và "-" nếu không.
※Phần “Điều kiện (input)” và “Hoạt động (output)” không bắt buộc lúc nào cũng phải là “Y“ “N“ “X“ “-“ mà có thể điền giá trị thực tế. Mình nghĩ là chỉ cần đảm bảo cover đủ các giá trị và các tổ hợp của input, output là được.
Step5：Rút gọn Decision Table
Đôi khi chúng ta có thể kết hợp các cột với nhau để có được một Decision Table ngắn gọn hơn.
Nếu trong bảng có một số cột có cùng kết quả output thì chúng ta có thể xem xét để gộp lại thành 1 rule duy nhất. Trong các cột này, một số điều kiện sẽ giống nhau và một số điều kiện sẽ khác nhau. Những cái khác nhau rõ ràng không ảnh hưởng đến kết quả. Vì vậy, chúng ta có thể thay thế các điều kiện khác nhau trong các cột đó bằng một dấu gạch ngang “-“. Dấu “-“ thường có nghĩa là tôi không quan tâm, hoặc giá trị nào cũng được.
Đầu tiên hãy nhìn vào rule 9~16, chúng ta có thể rút gọn được vì chỉ cần quan tâm đến điều kiện Real account = “N” (những giá trị của các điều kiện khác không làm thay đổi kết quả output).
Tiếp theo hãy xem xét rule 3,4. Chúng ta có thể gộp rule 3 và 4 với nhau, vì không cần quan tâm đến giá trị của điều kiện “Location okay?”. Gộp 2 rule này với nhau sẽ được 1 rule với ý nghĩa là: nếu thẻ vượt quá hạn mức (Within limit? = “N”) thì chủ thẻ sẽ bị gọi, bất kể vị trí.
Tương tự logic trên, chúng ta có thể gộp rule 7 và 8 với nhau.
Tuy nhiên, hãy lưu ý chúng ta không thể gộp rule 2 với 3, vì sẽ dẫn đến cả 2 điều kiện “Within limit?” và “Location okay?” đều nhận giá trị “-“. Tuy nhiên nếu bạn nghiên cứu kĩ yêu cầu, bạn sẽ thấy rằng một trong hai điều kiện này phải là “N” để kích hoạt hành động “Call cardholder?”. Do đó, nếu cả 2 đều nhận giá trị tùy ý (giá trị “-“) thì sẽ không đúng. Để tránh rút gọn bảng sai, các bạn hãy chú ý yêu cầu và tiến hành một cách thận trọng nhé.
Ngoài ra, việc xóa đi các tổ hợp không thể xảy ra trong thực tế cũng có thể làm cho Decision Table gọn hơn.
Đến đây thì chúng ta đã hoàn thành việc tạo một Decision Table rồi!
3. Decision Table Testing
Là kỹ thuật test tạo testcase từ Decision Table. Cụ thể sẽ viết ít nhất 1 testcase cho mỗi rule. Phần điều kiện của rule chính là input, phần hành động chính là expected result của testcase. Chúng ta cần viết testcase cho toàn bộ các rule trong bảng.
4. Kết hợp với "Phân tích giá trị biên" và "Phân vùng tương đương"
Trong thực tế, có nhiều trường hợp chúng ta cần phải kết hợp Decision Table với các kĩ thuật khác như Boundary value analysis và Equivalence partition để đảm bảo phạm vi test.
Trước hết, hãy xem thử rule No9 của Decision Table bên trên nhé.
Áp dụng kĩ thuật Phân vùng tương đương cho câu hỏi “Có những cách nào để có một tài khoản không có thật?”, chúng ta có thể có được những trường hợp bên dưới:
・Card number và Card holder (Name) không match
・Card number và Date (Expiry) không match
・Card number và Mã số bảo mật của thẻ (CSC) không match
・2 trong số 3 trường hợp trên (có tất cả 3 pattern như vậy)
・Cả 3 trường hợp trên
Do đó, đối với rule No9 chúng ta có thể tạo được 7 testcase.
Còn với kỹ thuật Phân tích giá trị biên thì sao nhỉ? Chúng ta thử phân tích các rule No1~7 và trả lời cho câu hỏi “Có bao nhiêu giá trị test liên quan đến hạn mức tín dụng?”
Áp dụng BE và EP, chúng ta có thể tìm ra được những trường hợp như dưới đây:
Tài khoản bắt đầu giao dịch ở mức số dư bằng Zero
Tài khoản sẽ ở mức số dư bình thường sau khi giao dịch
Tài khoản sẽ ở mức số dư vừa bằng với hạn mức sau khi giao dịch
Tài khoản vừa đủ vượt quá hạn mức sau khi kết thúc giao dịch
Tài khoản bắt đầu giao dịch ở mức số dư vừa bằng với hạn mức (do đó chắc chắn sẽ quá hạn mức nếu tiến hành giao dịch)
Tài khoản sẽ ở giá trị thấu chi tối đa sau giao dịch (có thể không thực hiện được trong thực tế, do đó sẽ không tạo testcase cho trường hợp này)
Kết hợp với Decision table, chúng ta sẽ có bộ testcase cuối cùng như bên dưới:
Nếu muốn đảm bảo rằng tất cả các equivalence class của điều kiện Within limit? = “Y” đều được thể hiện trong case giao dịch thành công, chúng ta có thể thêm testcase cho rule No1 như bên dưới:
5. Lời kết
Lần này mình đã giới thiệu về kĩ thuật Decision Table Testing. Kĩ thuật này rất hiệu quả khi sử dụng để test những logic phán định mà kết quả output thay đổi tùy thuộc vào sự kết hợp của các điều kiện input. Ngoài ra, nếu tài liệu đặc tả phức tạp thì việc lập Decision Table cũng giúp bạn sắp xếp lại các yêu cầu một cách rõ ràng hơn, cũng như có thể dùng làm tài liệu khi làm việc với các thành viên trong team dự án vì bảng quyết định trình bày, minh họa các vấn đề dưới dạng bảng giúp cho mọi người dễ hiểu hơn. Hy vọng qua bài viết này có thể giúp các bạn sử dụng Decision Table trong công việc testing của mình một cách hiệu quả. Cảm ơn mọi người đã dành thời gian để đọc bài viết này nhé!
【Tham khảo】
Advanced Software Testing - Vol. 1: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst (Rex Black)