Hôm nay mình sẽ nói tiếp tới 1 kỹ thuật thường hay dùng trong Black Box Testing đó là Decision Table Technique. Kỹ thuật này giúp xác định những kịch bản test cho những Business Logic phức tạp.
- Mình sẽ bắt đầu bằng 1 ví dụ như sau
Bạn được giao test cho 1 application tính toán discount cho khách hàng nhân dịch khuyến mãi. Điều kiện khuyến mãi như sau:
- Nếu là 1 khách hàng (KH) mới thì được giảm 10%
- Nếu là khách hàng hiện thời thì được giảm 15%
Câu hỏi đặt ra là với 2 điều kiện này thì bạn sẽ cần phải test bao nhiêu trường hợp để đảm bảo logic hoạt động đúng như requirement, không bị miss bất kì khả năng nào?
Decision Table đề xuất 1 cách đó là lập bảng khả năng. Nó sẽ trông như thế này 🙂
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
KH mới (15%) | ||||
KH hiện thời (10%) |
Như các bạn thấy, với 2 điều kiện thì có tất cả 4 khả năng có thể xảy ra. Và với mỗi khả năng sẽ có 2 giá trị True or False. Ta đánh nó tương ứng vào các ô.
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
KH mới (15%) | T | T | F | F |
KH hiện thời (10%) | T | F | T | F |
Một qui tắc để tính được số trường hợp khả năng là 2n. Với n là số điều kiện.
Từ bảng khả năng, ta có thể xác định giá trị Output tương ứng với từng trường hợp như bảng dưới đây.
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
KH mới (15%) | T | T | F | F |
KH hiện thời (10%) | T | F | T | F |
Actions/Outcomes | ||||
Discount 15% | Y | Y | ||
Discount 10% | Y | Y |
Hãy phân tích 1 chút về bảng trên. Với Rule 2, khi KH chỉ chọn option là KH mới thì Output sẽ là được discount 15%. Điều đó cũng tương đương khi KH chỉ chọn option là KH hiện thời. Nhưng nếu KH chọn cả 2 option (Rule 1) hoặc không chọn option nào (Rule 4) thì sao? Những mô tả này hoàn toàn không được đề cập khi ta đọc yêu cầu từ ban đầu.
Do vậy bảng decision cho phép ta nhìn thấy những những thiếu sót và mơ hồ trong mô tả.
Để khắc phục trường hợp trên, ta có thể đặt câu hỏi với ngưới viết ra requirment để hỏi họ xem sẽ quyết định như thế nào trong những trường hợp mô tả chưa rõ như thế.
Giả sử nếu họ muốn hiện một thông báo tới người dùng trong 2 trường hợp đó thì ta sẽ có 1 bảng decision như sau:
Conditions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
KH mới (15%) | T | T | F | F |
KH hiện thời (10%) | T | F | T | F |
Actions/Outcomes | ||||
Result | Error message | 15% | 10% | Error message |
Như vậy với kỹ thuật này ta có thể đi qua xét tất cả các khả năng có thể xảy ra bằng cách phối các điều kiện lại với nhau và phát hiện thiếu sót từ sớm.
2. Bài học kinh nghiệm
Ví dụ mình đưa ra chỉ có 2 điều kiện nên việc lập bảng có vẻ dễ nhưng bạn hãy tưởng tượng trong thực tế có những requiment có từ 9 hoặc 10 điều kiện thì sao? Nếu áp dụng 1 cách cứng nhắc thì bạn sẽ có 29 và 210 khả năng phải xét. Nó sẽ không khả thi và bất hợp lí khi phải xét hết tất cả khả năng như vậy, đăc biệt khi bạn chỉ có 1 thời gian cho phép.
Một số lưu ý khi lập bảng:
- Đừng giả định phải phối hết tất cả các điều kiện.
- Chỉ chọn lọc và ưu tiên lấy nhưng điều kiện quan trong nhất để phối.
- Xem xét những thứ cần test hoặc không cần test cho từng giai đoạn thời gian khác nhau
Và tùy vào từng trường hợp cụ thể nên áp dụng nhiều kỹ thuật khác để tạo ra một bộ test data hợp lí và vừa đủ.