Test case và Test scenario - Cái nào tốt hơn?

6 năm trước, khi tôi đang làm việc cùng với một MNC tầm trung, tôi đề nghị làm tài liệu test scenario chứ không phải lãng phí thời gian vào cách làm tài liệu một cách đầy đủ, chi tiết hay người ta gọi đó là tạo nên các test case. Mặc dù không ai phản đối ý tưởng nhưng thậm chí cũng không ai chấp nhận ý tưởng đó. Mọi người đều cảm thấy rằng nên làm theo cách truyền thống sẽ tốt hơn, ví dụ viết tài liệu test cases sẽ an toàn hơn, và tôi không thể tranh luận.

4 năm sau, công ty nhận được một dự án testing, với dự án này, thời gian rất hạn chế, và họ chỉ chú trọng vào việc các kết quả mong muốn được thực hiện chính xác. Chúng tôi đã họp bàn để đưa ra những phương pháp làm việc hợp lý. Dự án này là xây dựng một ứng dụng tìm kiếm để đưa ra các báo cáo khác nhau thông qua các menu khác nhau. Và việc tạo ra tài liệu test cases chiếm gần hết thời gian chúng tôi có, nhưng chúng tôi không chắc tài những tài liệu đó bao nhiêu phần trăm khách hàng có thể xem đó là hữu ích. Tôi đề nghị tạo tài liệu test scenarios, mọi người đồng ý. Không cần quá nhiều thời gian cho việc tạo tài liệu mà vẫn có thể dùng nó để run test.

Có thể thay thế test cases bằng test scenarios một cách nhanh chóng được không?

Trải qua thời gian, mọi thứ đều thay đổi, nghành khoa học phát triển phần mềm thay đổi và quá trình này cũng vậy.

Mô hình waterfall và v-models đang được thay thế bởi mô hình agile và iterative models. Việc tạo tài liệu là cần thiết, nhưng để tiết kiệm thời gian và quá trình thực hiện được nhanh gọn hơn thì việc thay đổi cách viết tài liệu là rất cần thiết.

** Tài liệu là test cases quan trọng trong các trường hợp:**

1. Khách hàng yêu cầu test cases giống như một phần không thể thiếu của dự án.

2. Không có ràng buộc về thời gian (tôi không nghĩ điều này là khả thi).

3. Tester là freshers hoặc chưa biết rõ về sản phẩm.

4. Quy định của công ty (tôi thiết nghĩ điều này có thể thay đổi được).

   Tôi xin được chia sẻ với các bạn một số kinh nghiệm của mình:

Tôi và team của tôi đã được tham gia vào dự án kiểm thử từ fortune 500 công ty với thời gian linh hoạt. Chúng tôi tạo ra test case tốt nhất và được sự chấp nhận từ khách hàng. Công việc được tiến hành bởi đội ngũ QA, hầu hết các ngày, nhiệm vụ của chúng tôi là tạo ra 100 test cases mỗi ngày một cách máy móc, cập nhật trạng thái test case true/fail và gửi cho khách hàng. Hầu hết các thành viên bắt đầu phàn nàn về công việc nhàm chán, đơn điệu, tuy nhiên công ty lại kiếm được doanh thu từ công việc đó.

Sau đó, đã có thay đổi, một ngày chúng tôi không ai tạo ra test cases mới, chúng tôi ngồi lại với nhau vào lúc đầu ngày để thảo luận chúng ta sẽ làm gì trong ngày hôm nay. Khi tôi đề xuất nên thêm ý tưởng để cải thiện các tài liệu test cases, tất cả các thành viên trong nhóm từ chối, Theo họ không có gì phải suy nghĩ khi họ đã cover hết tất cả scenarios. Việc thuyết phục họ thoát ra khỏi vùng an toàn để thay đổi lối làm việc quả là khó khăn.

Hầu hết thời gian chúng tôi ngồi tạo ra test cases và việc đó đã đừng chấp thuận từ phía khách hàng, tâm lý của mọi người nghĩ rằng họ đang thực hiện đúng công việc của mình và họ tự động ngừng suy nghĩ xem có cách nào khác thay đổi công việc của họ.

Và tôi tin rằng, tài liệu test cases được tạo ra, chúng tôi chỉ đang làm việc một cách máy móc để hoàn thành nó, Hãy cho tôi biết bao nhiêu lần trong sự nghiệp của bạn mà bạn hoặc team của bạn cung cấp các test cases bổ sung cho tài liệu test case đã được phê duyệt.

Kinh nghiệm:

Trong tuần thử thách hoạt động của team, Chúng tôi công bố các ứng dụng và yêu cầu các thành viên trong nhóm nêu ý tưởng về test scenarios của ứng dụng đó. Tất cả các thành viên trong nhóm đều không có ý tưởng gì hoặc ý tưởng rất mờ nhạt và không hứng thú., Tại sao? Không có tài liệu chính thức mà họ phải điền vào kết quả dự kiến cho mỗi chuỗi các chức năng và điều kiện tiên quyết cho mỗi test case. Chúng tôi nhận được 40 test scenarios trong một ngày và đó là một kinh nghiệm tuyệt vời.

Ví dụ:

Một mẫu form đăng nhập với tên truy cập, mật khẩu, nút đăng nhập, và h nút cancel. Nếu được yêu cầu viết test cases cho form đó, chúng ta sẽ tạo được hơn 50 test cases bằng cách kết hợp tùy chọn khác nhau.

Nhưng nếu viết test scenarios thì chúng ta chỉ có 10 dòng mà thôi.

Scenario mức tổng quát: Chức năng đăng nhập

Scenario mức chi tiết:

1. Kiểm tra ứng dụng được ra mắt
2. Kiểm tra nội dung văn bản trên trang đăng nhập
3. Kiểm tra Tên trường
4. Kiểm tra trường mật khẩu
5. Kiểm tra Login Button và cancel button.

Chúng ta có thể tiết kiệm được thời gian mà hiệu quả sử dụng tài liệu vẫn như nhau giữa test cases và test scenarios.

Cuối cùng, tôi xin tóm tắt sự khác biệt như sau:

Kết luận:

Test cases là một phần quan trọng của vòng đời phát triển phần mềm, không có nó chúng ta sẽ gặp khó khăn trong việc hiểu và theo dõi chất lượng dự án. Nhưng trong thời đại của Agile, test cases đang được thay thế nhanh chóng bởi các test scenarios. Tùy theo sự khẩn thiết về thời gian và hiểu biết của các thành viên về dự án mà lựa chọn test cases hay test scenario cho dự án của mình.

Bài viết được dịch lại từ nguồn: http://www.softwaretestinghelp.com/test-cases-vs-test-scenarios/