Test case và Test Scenario. Loại nào ưu việt hơn?

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 trong bài viết này chúng ta cùng làm rõ hơn về Test case và Test Scenario:

1. Test Case là gì?

Theo ISTQB Glossary of Testing Terms 2.1 (ISTQB) thì Test Case được định nghĩa như sau:

Test Case là một tập hợp các giá trị nhập, các điều kiện tiên quyết thực thi, các kết quả mong đợi và các điều kiện kết thúc, được xây dựng cho mục đích hoặc điều kiện kiểm thử riêng biệt, như thực hiện một đường dẫn chương trình riêng hoặc để kiểm tra lại đúng với yêu cầu của spec. [Theo IEEE 610]

Lưu ý rằng quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì lý do này, việc chuẩn bị test case sớm nhất có thể trong qui trình phát triển phần mềm là rất hữu ích.

2. Test Scenario là gì?

Theo Glossary của tài liệu ISTQB thì Test Scenario được mô tả như là Sự đặc tả phương thức kiểm thử.

Sự đặc tả phương thức kiểm thử là một tài liệu xác định một chuỗi các hành động để thực hiện một thử nghiệm. Nó còn được biết đến như là kịch bản nghiệm thử tự động (test script) hoặc kịch bản thử nghiệm bằng tay (manual test script). [Sau khi IEEE 829]

Ngoài ra Test Scenario – thường có được trực tiếp từ các đặc tả yêu cầu của khách hàng hoặc user-story. Các công cụ quản lý thường bỏ qua Test Scenario để kết nối với một danh sách các đặc tả yêu cầu. Scenario chứa một danh sách các test case và nhiều phối hợp của chúng.

Từ hai khái niệm trên chúng ta có thể hiểu đơn giản: Test Scenario là tập hợp các testcase để test 1 form hoặc function, chỉ nêu mục đích, không chỉ ra các step cụ thể. Còn test case thì có step cụ thể làm thế nào để test được.

3. Vậy câu hỏi đặt ra là liệu Test case có đang được thay thế nhanh chóng bằng Test Scenario hay không?

Với thời gian, khi tất cả mọi thứ đang thay đổi, ngành công nghiệp phần mềm và quá trình phát triển ngành công nghiệp này cũng đã thay đổi rất nhiều. Các mô hình truyền thống như: Waterfall hay V-model đang được thay thế dần dần bởi mô hình Agile và Iterative. Tài liệu là cần thiết nhưng để đáp ứng thời hạn và làm cho quá trình dễ dàng và minh bạch hơn , cách làm tài liệu có thể được thay đổi.

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.
• Expected 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.
• Pre-condition 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?

Trong khi đó Test Scenario đ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 chức năng Login

1. Kiểm tra ứng dụng chuẩn bị được ra mắt
2. Kiểm tra nội dung các text trên trang đăng nhập có đúng theo design hay không
3. Kiểm tra trường Username
4. Kiểm tra trường Password
5. Kiểm tra Login button có hoạt động đúng như design hay không

Khi dự án không có nhiều thời gian, Test Scenario sẽ là một lựa chọn tối ưu cho dự án. Và nó cũng vẫn đạt được hiệu quả cao như việc tạo Test Case.

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

|_.               |_. Test Cases |_. Test Scenarios |
|    **Khái niệm =>**     | Một khái niệm cung cấp thông tin chi tiết cái phải test, các bước thực hiện và dự kiến kết quả.  | Một khái niệm cung cấp một dòng thông tin về những gì cần phải  kiểm tra.|
| **Chi tiết =>** | Tài liệu thì cần phải chi tiết.  | Thiên về suy nghĩ và thảo luận chi tiết các kịch bản có thể xảy ra cùng cả team.|
| **Tầm quan trọng  =>** | Viết TC chi tiết sẽ giúp:
-  QA mới ra trường chưa có nhiều kinh nghiệm dự án.
- Những người vào  sau hiểu rõ bạn đã test cái gì và test như thế n ào.
- Giúp QA và Dev có thể hiểu rõ và đồng bộ hơn. | Khi dự án có ít thời gian và hầu hết các thành viên trong dự án có thể đồng ý/ hiểu chi tiết từ một danh sách các kịch bản.|
| **Ưu điểm  =>** | -  Có thể tái sử dụng lại nhiều lần trong tương lai.
- Về mặt  thời gian thì việc tạo test case rất hữu ích trong việc report lỗi. Tester chỉ cần cung cấp tài liệu tham khảo của test case ID mà không cần đề cập  chi tiết.
 | -Tiết kiệm thời gian và tích cực tạo ra ý tưởng mới, nó được ưa chuộng bởi thế hệ mới của  cộng đồng kiểm thử phần mềm.
 - Việc sửa đổi và bổ sung thì đơn giản hơn và không giao cụ thể cho một người.
 - Đối với một dự án lớn, nơi mà một group chỉ biết các module cụ thể thì việc sử dụng Test Scenario sẽ mang lại một cơ hội để mọi người  có thể dễ dàng thảo luận và đưa ra những sáng kiến khi nhìn vào những module khác.|
| **Lợi ích =>** | Tài liệu này sẽ thực sự quan trọng cho những tester mới ra trường chưa có kinh nghiệm trong việc testing hệ thống .| Test Scenario có thể đạt được độ che phủ tốt nhất bằng cách chi nhỏ các ứng dụng mặt khác nó cũng làm giảm mức độ lặp lại của sản phẩm.|
| **Nhược điểm =>** | Tốn thời gian và tiền bạc vì nó đòi hỏi nhiều nguồn nhân lực để có thể hiểu chi tiết về những thứ phải kiểm thử và làm cách nào để có thể kiểm thử.  | Nếu Test Scenario được tạo ra bởi một người cụ thể thì những người sử dụng lại sẽ không thể hiểu hết được chính xác ý tưởng của người trước, nó sẽ cần thêm các buổi thảo luận nhóm do đó sẽ tốn thêm nhiều effort để làm rõ các kịch bản trước đó.|

5. Kết luận

Test case là một phần rất quan trọng trong SDLC và không thể thiếu nó. Test case giúp cho mọi người có thể hiểu và thực hiện một cách dễ dàng. Nhưng trong thời đại của Agile, Test case đang dần dần được thay thế bằng Test scenario.

Một checklist phổ biến cho mỗi loại kiểm thử (Database, GUI, Function,vv..) kết hợp với Test scenario là những những pháo hiện đại cho các nhân viên kiểm thử phần mềm. Thảo luận, các khóa đào tạo, các câu hỏi và thực hành chắc chắn có thể thay đổi đồ thị cuối cùng của sản phẩm của bạn cũng như ma trận báo cáo lỗi.