Kịch bản kiểm thử - Test Scenario

Test Scenario tuy không còn mới mẻ nhưng không ít người còn mơ hồ về khái niệm này. Vậy Kịch bản kiểm thử - Test Scenario là gì? Tại sao phải tạo Test Scenario?  Cách tạo Test Scenario như thế nào? Hãy đọc bài viết này nhé.

1. Kịch bản kiểm thử - Test Scenario là gì?

Kịch bản kiểm thử - Test Scenario bao gồm tất cả các chức năng có thể được kiểm thử. Test Scenario cũng được gọi là Test Condition hoặc Test Possibility. Là một tester, bạn có thể đặt mình vào vị trí của người dùng cuối và tìm ra các tình huống trong thực tế và các trường hợp có thể xảy ra của ứng dụng đang được kiểm thử.

2. Kiểm thử kịch bản - Scenario Testing là gì?

Kiểm thử kịch bản là một biến thể của Kiểm thử phần mềm trong đó Kịch bản được sử dụng để kiểm thử. Các kịch bản giúp dễ dàng kiểm thử các hệ thống phức tạp.

3. Tại sao phải tạo Kịch bản kiểm thử?

Kịch bản kiểm thử được tạo ra vì những lý do sau đây:

Bài viết này được đăng tại [free tuts .net]

• Tạo các kịch bản kiểm thử đảm bảo hoàn thành Test Coverage
• Kịch bản kiểm thử có thể được thông qua bởi các bên liên quan khác nhau như Nhà phân tích nghiệp vụ (BA), Developers, Khách hàng để đảm bảo ứng dụng được kiểm thử kỹ lưỡng và đảm bảo rằng phần mềm đang hoạt động tốt.
• Kịch bản kiểm thử như một công cụ nhanh chóng để xác định effort kiểm thử, dựa theo đó tạo ra đề xuất cho khách hàng hoặc tổ chức về nguồn lực lao động.
• Kịch bản kiểm thử giúp xác định các giao dịch đầu cuối quan trọng nhất hoặc xác định việc sử dụng các ứng dụng phần mềm trong thực tế.
• Để nghiên cứu chức năng đầu cuối, Kịch bản kiểm thử là rất quan trọng.

4. Khi nào không tạo Kịch bản kiểm thử?

Kịch bản kiểm thử có thể không được tạo khi:

• Ứng dụng đang kiểm thử rất phức tạp, không ổn định hoặc dự án đang rơi vào một thời gian khủng hoảng.
• Các dự án tuân theo Phương pháp Agile như Scrum, Kanban có thể không tạo Kịch bản kiểm thử.
• Kịch bản kiểm thử có thể không được tạo khi sửa lỗi mới hoặc khi thực hiện kiểm thử hồi quy. Trong các trường hợp như vậy, Kịch bản kiểm thử phải được lưu lại nhiều trong các chu kỳ kiểm thử trước đó. Điều này đặc biệt đúng với các dự án bảo trì.

5. Cách tạo Kịch bản kiểm thử

Là người kiểm thử, bạn có thể làm theo năm bước sau để tạo Kịch bản kiểm thử:

• Bước 1: Đọc các Tài liệu yêu cầu như BRS, SRS, FRS của Hệ thống đang kiểm thử (System Under Test - SUT). Bạn cũng có thể tham khảo các uses cases, sách, hướng dẫn…của ứng dụng sẽ được kiểm thử.
• Bước 2: Đối với mỗi yêu cầu, hãy tìm ra các hành động và mục tiêu có thể của người dùng. Xác định các khía cạnh yêu cầu kỹ thuật. Xác định các tình huống có thể xảy ra về lạm dụng hệ thống và đánh giá người dùng với suy nghĩ của hacker.
• Bước 3: Sau khi đọc Tài liệu yêu cầu và thực hiện Phân tích, hãy liệt kê các kịch bản kiểm thử để xác minh từng tính năng của phần mềm.
• Bước 4: Khi đã liệt kê tất cả các kịch bản kiểm thử có thể, Ma trận truy xuất nguồn gốc được tạo để xác minh rằng mọi yêu cầu đều có kịch bản kiểm thử tương ứng
• Bước 5: Các kịch bản được tạo ra được xem xét bởi người giám sát và các bên liên quan trong dự án.

6. Lời khuyên để tạo kịch bản kiểm thử

• Mỗi kịch bản kiểm thử phải được gắn với tối thiểu một yêu cầu trong dự án.
• Trước khi tạo kịch bản kiểm thử xác minh nhiều yêu cầu cùng một lúc, hãy đảm bảo đã có kịch bản kiểm thử cho mỗi yêu cầu riêng lẻ.
• Tránh tạo các kịch bản kiểm thử quá phức tạp, nhiều yêu cầu kéo theo.
• Số lượng kịch bản có thể lớn và tốn kém để bao phủ tất cả. Dựa trên những ưu tiên của khách hàng, chỉ chạy các kịch bản kiểm thử được chọn.

7. Ví dụ minh họa

Ví dụ 1: Kịch bản kiểm thử cho đặt chỗ chuyến bay

Đối với ứng dụng Đặt chỗ chuyến bay, một số kịch bản kiểm thử như sau:

Kiểm thử kịch bản 1: Kiểm thử chức năng đăng nhập

Kịch bản kiểm thử 2: Kiểm thử xem Đơn hàng mới có thể được tạo không

Kịch bản kiểm thử 3: Kiểm thử xem Đơn hàng hiện tại có thể được mở không

Kiểm thử kịch bản 4: Kiểm thử xem người dùng có thể đặt hàng FAX không

Kịch bản kiểm thử 5: Kiểm thử xem thông tin được hiển thị trong phần HELP có chính xác không

Kiểm thử kịch bản 6: Kiểm thử xem thông tin được hiển thị trong phần ABOUT, như version, programmer name, copy right… thông tin phải hiển thị chính xác

Ngoài những kịch bản trên, còn có các kịch bản như sau:

• Cập nhật đơn hàng
• Xóa đơn hàng
• Kiểm tra báo cáo
• Kiểm tra bản đồ

Chúng ta đã biết kiểm thử tất cả là không thể. Giả sử bạn chỉ có thời gian để thực hiện 4 trong số 6 kịch bản trên, trong đó có hai kịch bản ưu tiên thấp hơn trong sáu kịch bản sẽ bị loại bỏ, bạn sẽ lựa chọn kịch bản nào?

Chắc chắn hầu hết các bạn sẽ đoán được kịch bản 5 và 6 vì chúng không phải là chức năng cốt lõi của ứng dụng, do đó không được ưu tiên kiểm thử.

Ví dụ 2: Kịch bản kiểm thử cho một trang web ngân hàng

Kịch bản kiểm thử 1: Kiểm thử chức năng đăng nhập và xác thực

Kịch bản kiểm thử 2: Kiểm thử chức năng chuyển tiền có thể được thực hiện

Kịch bản kiểm thử 3: Kiểm thử chức năng sao kê tài khoản có thể được xem

Kịch bản kiểm thử 4: Kiểm thử chức năng tiền gửi cố định / tiền gửi định kỳ có thể được tạo