Test Case Trong Kiểm Thử Phần Mềm
Test Case là gì? có lẽ là câu hỏi được hỏi trong tất cả các cuộc phỏng vấn kỹ sư kiểm thử phần mềm. Hãy cùng VNTesters tìm hiểu về TC nhé. Nó không những giúp bạn vượt qua vòng phỏng vấn một cách ấn tượng, mà còn giúp bạn đi xa hơn trong sự nghiệp.
Test Case là gì?
Có rất nhiều định nghĩa khác nhau về Test Case. Mỗi tổ chức định nghĩa theo cách riêng của họ. Dưới đây là định nghĩa về TC của VNTesters. Mình cố ý định nghĩa lại để các bạn mới làm quen với kiểm thử phần mềm có thể dễ dàng nhớ và trả lời khi phỏng vấn.
Test Case là tài liệu (artifacts) trong kiểm thử phần mềm. Nó mô tả hành động của Tester (hoặc automation tool) cần thực hiện để tương tác với ứng dụng cần kiểm thử (application under test – AUT) và phản ứng cần có hoặc không được phép của ứng dụng trước tác động của Tester.
Tại sao cần phải viết Test Case?
Dưới đây là một số lý dó chính theo quan điểm của VNTesters.
- Để tìm bug
- Để đo lường mức độ bao phủ (test coverage)
- Độ tái lập (Reproducibility)
- Để theo dõi (tracking)
- Để quy trách nhiệm
- Để xác minh rằng các bài kiểm tra đang được thực hiện chính xác
- Sử dụng làm công cụ đào tạo cho Tester mới
- Tuân thủ (for compliance)
Các thành phần cơ bản
Tùy vào yêu cần của mỗi dự án mà test case template có thể được điều chỉnh cho phù hợp. Dưới đây VNTesters liệt kê một số thành phần hay được sử dụng nhất. Có một số thành phần mình không giải thích vì nó đã rõ ràng và hiển nhiên (vd: author, notes…)
| Test Case ID | Mã TC có thể là số hoặc chữ và số kết hợp. VD: FN_ComponentA_SubComponentAB_001. Nhờ vào cách đánh mã này mà Tester có thể dễ dàng nhận ra đây là Functional Test Case cho ComponentA/SubComponentAB. |
| Test Summary / Description | Mô tả ngắn gọn về TC hoặc mục tiêu của TC. |
| Related test requirements | Những yêu cầu kiểm thử sẽ được bao phủ (cover) trong TC. |
| Prerequisites / Pre-condition | Điều kiện tiên quyết cần phải có trước khi thực hiện kiểm thử. |
| Test steps / procedure | Quy trình kiểm tra mô tả chi tiết từng bước cần thực hiện và cần kiểm tra những gì (verification points), mong đợi gì từ ứng dụng (expectation) |
| Test data | Dữ liệu được sử dụng trong quá trình tương tác với ứng dụng. |
| Expected Result | |
| Observed Result | |
| Status | |
| Environment | |
| Tracking information | |
| Notes / comments | |
| Author | |
| Test category | |
| Able to automate? |
Một số kỹ thuật viết Test Case thông dụng
Mình tính dịch sang tiếng Việt mà thấy nó kỳ kỳ, anh chị em dịch giúp mình nhé.
- Equivalent Partitioning
- Boundary Analysis
- Constraint Analysis
- State Transition
- Condition Combination
Những kỹ thuật viết TC ở trên khá phổ biến nên các bạn ráng nắm rõ nhé. Ngoài ra còn một số kỹ thuật ít phổ biến hơn như
- Cause-Effect Grapping
- Syntax Testing
- Statement Testing
- Branch/Decision Testing
- Data Flow Testing
- Branch Condition Testing
- Branch Condition Combination Testing
- Modified Condition Decision Testing
- LCSAJ Testing (Linear Code Sequence and Jump)
- Random (Ad hoc) Testing
Đặc tính của một Test Case “xịn”
- Ngắn gọn, dễ hiểu không cần tác giả giải thích hoặc phải tham chiếu đến tài liệu khác để hiểu.
- Không quá đơn giản hoăc quá phức tạp. Đủ chi tiết để bất cứ Tester nào cũng có thể run test được.
- Chính xác và tập trung vào mục đích của kiểm thử
- Có tiêu chí rõ ràng cho Pass hoặc Fail
- Xác suất bắt được bug “hợp lý”
- Không trùng lặp với bất kỳ TC nào khác
Bonus: TC trong mô hình Agile/DevOps
Rất nhiều dự án đã, đang và sẽ áp dụng mô hình phát triển phần mềm này. Việc viết Test Case dần trở thành gánh nặng không cần thiết. Để thích nghi với mô hình Agile/DevOps, các thành phần ít quan trọng của Test Case dần bị lược bỏ và Test Case trở thành checklist. Checklist tập trung vô tiêu chí để quyết định checklist đó Pass hoặc Fail.