Một bộ testcase cơ bản cần những gì???
Với một intern tester khi mới bắt đầu được người hướng dẫn giao việc viết testcase cho 1 chức năng cơ bản, chắc bạn cũng rất thắc mắc nó bao gồm những gì đúng không? Sau đây chúng ta cùng tìm hiểu khi tạo 1 bộ testcase thì sẽ bao gồm những thành phần gì nhé!!!
1.Khái niệm cơ bản
- Test case là một trường hợp cần kiểm thử, nó bao gồm các thao tác/hành động trên hệ thống, điều kiện cần (tiên quyết), các giá trị đầu vào, và kết quả mong đợi. Một test case thì nên chỉ kiểm tra một trường hợp, một khía cạnh cụ thể nào đó chứ đừng lan man. Test case thường có 2 loại chính: test case chi tiết và test case cơ bản ( nguồn: https://glossary.istqb.)
2. Bộ testcase thì bao gồm những thành phần gì
Trong thực tế test case được trình bày theo nhiều định dạng khác nhau, có thể sử dụng MS Excel hoặc công cụ nào đó để quản lý test case như TestLink hoặc TestRail. Dù test case được trình bày theo dạng nào, thì thành phần chính của test case cũng bao gồm các thông tin sau:
- Test case ID (hay gọi tắt là Test ID): Mã trường hợp kiểm thử
Là mã số được gán cho mỗi test case để tiện quản lý, ví dụ ADD-01
Trong đó, “ADD” là viết tắt của Tên Chức năng hoặc Màn hình tương ứng. “01” là số thứ tự.
Lưu ý Test case ID không được trùng nhau. - Test description
Tóm tắt trường hợp đang được kiểm thử. Ví dụ:
TC1: Kiểm tra trường hợp đăng nhập thành công với một bộ tài khoản hợp lệ
TC2: Người dùng không thể đăng nhập thành công với tài khoản đang bị khoá - Test precondition (hoặc là setup steps)
Các điều kiện tiên quyết, bắt buộc phải hoàn thành trước khi thực hiện trường hợp kiểm thử này. Ví dụ: Với test case TC1 ở trên (Kiểm tra trường hợp đăng nhập thành công với một bộ tài khoản hợp lệ) thì bạn phải chuẩn bị sẵn một bộ tài khoản hợp lệ bao gồm username và password - Test steps (hoặc steps)
Các bước chi tiết của một trường hợp kiểm thử. Bạn có thể viết cơ bản, ngắn gọn hoặc viết chi tiết bao gồm dữ liệu cụ thể (test data) - Expected result
Kết quả mong đợi là điều mà bạn mong đợi chương trình/hệ thống thực hiện sau khi bạn đã thực hiện các bước ở phần “Test steps” - Status (hoặc Test result)
Nếu kết quả quan sát giống như kết quả mong đợi thì chỗ này sẽ được điền là “OK” hay “ĐẠT”
Ngược lại, thì là “NG” hay “KHÔNG ĐẠT” - Bug ID
Nếu trường hợp kiểm thử vừa được thực hiện là KHÔNG ĐẠT thì bạn sẽ POST BUG, sau đó ghi ID của con bug đó vào đây. - Và nhiều thông tin khác nữa tuỳ nhóm bạn hay khách hàng muốn quản lý thêm thông tin gì.( vd như mức độ ưu tiên,thời gian test, ai là người test, test round1,2,3....)
3. Một vài câu hỏi thường hay thắc mắc
- Làm sao để viết test case bao phủ tốt?
Test case bao phủ tốt là phải bao gồm các loại test case cho UI (nếu có – vì giả sử bạn đang test API thì làm gì có UI mà bắt buộc phải có test case cho UI), test case cho các trường hợp happy case (positive case), và negative case (unhappy case). Và quan trọng hơn hết, tập test case của bạn phải bao phủ mọi nghiệp vụ, chức năng cần thiết theo mô tả yêu cầu.
- Có cần phải viết test case không?
Không phải dự án nào cũng có đủ thời gian để viết test case. Thông thường thì trong khi dev đang lập trình thì tester sẽ có thời gian để viết test case.
Nhưng cũng có nhiều trường hợp, dự án không hoàn toàn viết mới mà sẽ cải tiến, nâng cấp hệ thống cũ, thì thời gian lập trình thường sẽ hoàn thành trước thời gian viết test case. Và nhiều lúc cần gấp thì mình vẫn có thể test (kiểm thử) trước khi viết test case xong hoặc vừa kiểm thử vừa viết.
- Không viết test case có được không?
Việc có viết test case hay không sẽ phụ thuộc vào từng trường hợp cụ thể. Phụ thuộc vào ngữ cảnh, tình hình thực tế của dự án mà tester cân nhắc nên test trước rồi viết test case hay là viết test case trước rồi test. Ngoài ra, mọi việc còn phụ thuộc vào quyết định của Khách hàng, QC/Tester Leader và Project Leader/Manager nữa.