Viết Test Case từ 1 Scenario đã có

1. Định nghĩa Test Case và Scenario

Bất cứ ai làm về kiểm thử phần mềm đều hiểu thế nào là Test Case nhưng rất ít bạn biết về Test Scenario. Vì vậy trước khi tìm hiểu cách viết Test Case từ 1 Scenario đã có thì chúng ta cùng nhau định nghĩa lại Test Case và Scenario để có 1 cái nhìn tổng quát hơn. Test Scenario : Từ Test Plan, đi sâu hơn vào chi tiết của từng feature. Test scenario mô tả cái cần test, lưu ý là cái cần test. Ở đây có thể ví dụ một test scenario điển hình như: Test Login form và kiểm tra chắc chắn rằng nó hoạt động như mong muốn. Một test scenario có thể gồm nhiều test case.

Test Case : Tiếp tục đi sâu hơn vào chi tiết của test scenario. Test Case được ví như những đơn vị nhỏ nhất của từng test project, như các tế bào của một cơ thể sống. Điều quan trọng khi thiết lập 1 test case:

• Ít step nhất có thể và chắc chắn rằng chỉ có 1 bước verify cần thực hiện
• Intended result phải được miêu tả 1 cách rõ ràng. Một ví dụ cho việc mô tả không rõ ràng như sau: "test pass khi user login thành công". Thành công như thế nào? điều gì chứng tỏ login thành công? App hay web sẽ redirect user tới screen nào? Điều gì xác định là user đã được login? Tất cả phải được nêu một cách RÕ RÀNG NHẤT CÓ THỂ. Điều này là tối quan trọng nếu bạn muốn test case có thể được automate.
• Prerequisites phải được miêu tả rõ ràng. Những features nào phải hoạt động trước khi test case có thể chạy? Tester phải làm gì trước khi bắt đầu test case? Test case nào cần phải pass trước khi có thể chạy test case hiện tại?

Sự khác nhau giữa Test Case và Test Scenario :

Như vậy: Test scenario là 1 kịch bản trong đó có chứa các test case liên quan đến kịch bản đó.

Ví dụ: Test scenario: kiểm tra chức năng Sent email Test case nằm trong test scenario gồm :

• Check Sent button khi không có địa chỉ mail
• Check Sent button khi không có title
• Check Sent button khi nhập email không có trên server

Lúc đầu ta sẽ có Business Requirement gồm có chức năng Login, Sent mail, Purchase. Với chức năng Purchase ta lại có 2 loại user ứng với mỗi kiểu purchase tương ứng.

Mô hình sẽ đi như sau: BR_Login->UC_User->TC1_TC5 BR_Sentmail->UC_User->TC6_TC10 BR_Purchase->UC_NormalUser->TC11_TC20 BR_Purchase->UC_BusinessUser->TC21_TC30

Test scenario có thể bao gồm các test scenario nhỏ hơn bên trong. (UC là use case, ví dụ như use case admin, admin có thể quản lý bài viết, quản lý account; use case member thì edit account, đăng bài)

Sau khi đã định nghĩa Test Case và Scenario rõ ràng, chúng ta cùng sang mục tiếp theo:

2. Cách xây dựng Test Case từ 1 Scenario có sẵn

Để làm được điều này chúng ta cần trả lời 2 câu hỏi sau đây:

Question #1 :

Câu hỏi được đưa ra bởi 1 member trong softwaretestinghelp.com, nguyên văn câu hỏi như sau:

"**Trong 1 cuộc phỏng vấn tôi đã nhận được câu hỏi này : Hãy viết các Test case cho ngữ cảnh sau: Nếu bạn là 1 khách hàng mới và bạn muốn mở một tài khoản tín dụng, có 3 điều kiện :

• Thứ nhất : Bạn sẽ được giảm giá 15% cho tất cả các mặt hàng bạn mua ngày hôm nay
• Thứ hai : Nếu bạn đã là khách hàng thành viên và có thẻ khách hàng thân thiết, bạn sẽ được giảm 10% hóa đơn
• Thứ ba : Nếu bạn có phiếu giảm giá (coupon), bạn được giảm 20% hóa đơn ngay hôm nay (nhưng không áp dụng cho khách hàng mới). Số tiền chiết khấu được tăng thêm, nếu có.

Ai đó có thể giúp tôi không**"

Chắc chắn rồi. Happy to help!

Trả lời: Câu hỏi này là một trường hợp điển hình về xử lý khác nhau xảy ra đối với các loại đầu vào khác nhau. Đầu vào ở đây là loại khách hàng. Việc xử lý là tính số tiền chiết khấu mà họ có thể tận dụng được. Tùy thuộc vào loại đầu vào mà đầu ra sẽ khác nhau, trong trường hợp này sử dụng "Decision Table Testing - Bảng quyết định" sẽ rất hiệu quả. Hãy làm như sau:

Bước 1 : Phân chia đầu vào thành nhiều loại riêng. Để tạo một bẳng quyết định, bạn sẽ phải phân chia đầu vào của bạn thành các loại. Có 6 loại người dùng trong trường hợp này:

• Khách hàng mới có phiếu giảm giá
• Khách hàng mới không có phiếu giảm giá
• Khách hàng thành viên có thẻ khách hàng thân thiết và không có phiếu giảm giá
• Khách hàng thành viên không có thẻ khách hàng thân thiết và không có phiếu giảm giá
• Khách hàng thành viên có thẻ khách hàng thân thiết và có phiếu giảm giá
• Khách hàng thành viên không có thẻ khách hàng thân thiết và có phiếu giảm giá

Nếu nhóm cặp bất kỳ thì chúng ta có thể phân vùng thêm 1 số loại nữa ví dụ như khách hàng mới có thẻ khách hàng thân thiết ... nhưng từ định nghĩa/bài toán cũng không xác định rõ ràng được khả năng xảy ra các trường hợp này (liệu khách hàng mới thì có thể có 1 thẻ khách hàng thân thiết hay không, ...) nên chúng ta sẽ bỏ qua các vùng phân loại này.

Bước 2 : Xây dựng bảng quyết định. Có rất nhiều cách để làm điều này. Tôi sẽ sử dụng tất cả các loại đầu vào như các cột (column) và mức chiết khấu làm các hàng (row). Sẽ có bảng sau:

Bước 3: Chọn một loại người dùng từ mỗi loại đầu vào và kiểm tra Bây giờ từ mỗi loại, bạn có thể chọn một giá trị và kiểm tra để xem liệu số tiền chiết khấu chính xác được áp dụng là bao nhiêu. Bây giờ, bạn sẽ cần ít nhất 6 khách hàng hoặc 6 trường hợp thử nghiệm (test case) để bao phủ đầy đủ các trường hợp kiểm thử.

Tôi chắc chắn rằng vào thời điểm này bạn đang nghĩ, "Tất cả đã ổn. Nhưng làm thế nào tôi có thể trả lời câu hỏi trong cuộc phỏng vấn ngay lập tức khi tôi không có thời gian để giải quyết các giải pháp chi tiết như bạn đã làm? "

Đây là lý do tại sao điều quan trọng lại là nói lên được những suy nghĩ của bạn trong một cuộc phỏng vấn.

Ngay sau khi bạn nghe câu hỏi, bạn có thể nói: Tôi nghĩ rằng một bảng quyết định sẽ giúp giải quyết vấn đề này. Nếu người phỏng vấn muốn bạn xây dựng bảng quyết định, bạn có thể yêu cầu một tờ giấy và một cây bút và làm việc nó. Kèm theo đó hãy giải thích giải pháp của bạn.

Ngoài ra, hãy nhớ rằng, không quan trọng phải có ngay được kết quả chính xác 100%. Vì biết đâu có thể bạn sẽ bỏ sót một loại đầu vào nào đó thì sao, bởi vì áp lực trong một cuộc phỏng vấn hoặc trong sự vội vàng thì điều đó vẫn là chấp nhận được. Người phỏng vấn sẽ đánh giá cao chiến lược và sự rõ ràng của tư duy của bạn hơn đấy.

Để biết thêm thông tin về các bảng quyết định, hãy đọc thêm ở đây : How to Write Complex Business Logic Test Scenarios Using Decision Table Technique

Question #2

Câu hỏi này cũng được đưa ra bởi 1 thành viên trên softwaretestinghelp.com : "Nguyên tắc 80:20 là gì? Vui lòng giải thích qua ví dụ "

Answer: : Quy tắc 80/20 còn được gọi là nguyên tắc Pareto. Bạn có thể tìm hiểu một định nghĩa cơ bản ở đây theo nguyên tắc Pareto :

Nguyên tắc này nói rằng trong quy tắc 80/20 thì 80% kết quả là do 20% nguyên nhân. Nó có thể được áp dụng cho nhiều thứ và trong bối cảnh của một dự án CNTT QA, ví dụ :

• 80% năng suất của bạn là do 20% các hoạt động bạn làm
• 80% tiến độ được đóng góp bởi 20% đội của bạn
• 80% ứng dụng có thể được kiểm tra bởi 20% các trường hợp thử nghiệm
• 80% các trục trặc có thể được giải quyết bằng việc fix được 20% lỗi của bạn
• v.v....

Do đó, theo nguyên tắc này, chúng ta sẽ phải xác định 20% nguyên nhân đó.

Phân tích Pareto chỉ đơn giản là một kỹ thuật giúp bạn tối ưu hóa effort của mình. Thay vì phân phối trọng tâm và effort của bạn trên tất cả 100% nguyên nhân, nó chỉ cho chúng ta tìm kiếm 20% nguyên nhân mà khi được giải quyết sẽ tối đa hóa lợi nhuận của bạn (giải quyết được 80% các vấn đề).

• Đây không phải là một khoa học chính xác và không nên được đưa vào giá trị mặt.
• Phân tích Pareto chỉ ra việc sử dụng nó trong nhiều ngành công nghiệp chứ không chỉ là phần mềm.
• Để biết chính xác 20% nguyên nhân là gì, bạn có thể vẽ biểu đồ Pareto.

Nó là một sự kết hợp đơn giản của 3 trục (1 trục hoành, và 2 trục tung với 2 gốc tọa độ) và và đường vẽ:

• Biểu diễn các nguyên nhân trên trục X (sắp xếp theo chiều giảm dần số lượng các vấn đề) và các vấn đề trên trục Y (trái, số lượng vấn đề).
• Trục Y (phải) là tỉ lệ tái hiện (tần suất xuất hiện của lỗi) , giảm từ 100 - 0 (% trung bình)
• Các điểm chấm đỏ là tỉ lệ tái hiện và đường nối các điểm màu đỏ .

Tất cả các nguyên nhân nằm trong khoảng từ 0 đến dòng Y2 = 80 là các nguyên nhân thuộc nhóm 20% quan trọng.

Ví dụ : có 5 mô-đun trong một ứng dụng có khiếm khuyết được cố định và đây là sự phân bố của chúng:

Bây giờ, bạn sẽ sắp xếp lại bảng này theo thứ tự giảm dần số lỗi và tính toán tỷ lệ phần trăm tái hiện :

Biểu đồ Pareto cho dữ liệu bảng ở trên:

Bây giờ, để biết 20% mô đun quan trọng của bạn cần được fix để tối ưu hóa việc fix lỗi, hãy vẽ đường thẳng ở mức 80% trên trục tỷ lệ phần trăm tái hiện (Y2), như dưới đây:

Do đó, 20% mô-đun bạn nên tập trung là Module 1, 4 và 2 (Vùng khoanh tròn đỏ, là vùng nguyên nhân nằm trong khoảng từ 0 đến dòng Y2 = 80)

Vậy nên Test case bạn viết cũng nên tập trung vào 20% cause này để có thể đảm bảo kiểm soát được khoảng 80% bug có thể xảy ra của chương trình

Bài dịch trên còn nhiều thiếu sót, nếu bạn quan tâm có thể tham khảo bài viết gộc tại đây: http://www.softwaretestinghelp.com/how-to-write-test-cases-for-a-given-scenario/

Hẹn các bạn trong những bài tiếp theo nhé. Thanks for seeing ^^