Đọc Acceptance Criteria như thế nào để không bỏ sót Test Case? — Kỹ năng quan trọng của QA Engineer
Một trong những nguyên nhân khiến bug lọt sang production không phải vì QA thiếu kỹ năng sử dụng công cụ, mà vì QA chưa phân tích đầy đủ yêu cầu trước khi bắt đầu kiểm thử.
Developer hoàn thành chức năng theo yêu cầu. QA kiểm tra luồng chính và thấy mọi thứ hoạt động đúng. Tuy nhiên, sau khi release, người dùng phát hiện một trường hợp mà không ai nghĩ đến trong quá trình test.
Ví dụ, một chức năng cho phép Admin chọn tất cả thành viên trong danh sách. QA kiểm tra nút Select All hoạt động bình thường và đánh dấu Pass. Nhưng khi Admin bỏ chọn một thành viên, trạng thái Select All không được cập nhật. Một trường hợp khác xảy ra khi người dùng chuyển sang trang tiếp theo hoặc áp dụng bộ lọc.
Vấn đề ở đây không nhất thiết là QA không thực hiện kiểm thử. Có thể QA đã chưa chuyển đầy đủ yêu cầu thành các tình huống cần xác minh.
Vậy làm thế nào để đọc Acceptance Criteria (AC) có hệ thống và giảm nguy cơ bỏ sót test case?
1. Acceptance Criteria là gì và tại sao QA cần phân tích kỹ?
Acceptance Criteria là tập hợp các điều kiện mà một chức năng cần đáp ứng để được xem là hoàn thành theo yêu cầu nghiệp vụ.
AC giúp QA xác định:
Chức năng cần thực hiện hành vi gì.
Điều kiện nào cần được đáp ứng.
Kết quả nào được xem là đúng.
Những trường hợp nào cần được kiểm tra trước khi nghiệm thu.
Tuy nhiên, AC không phải lúc nào cũng mô tả đầy đủ mọi tình huống kiểm thử. Một AC có thể chỉ mô tả luồng chính mà chưa nói rõ cách hệ thống xử lý dữ liệu không hợp lệ, trạng thái biên, quyền truy cập hoặc các thao tác liên tiếp.
Vì vậy, nhiệm vụ của QA không chỉ là đọc AC rồi viết lại thành test case. QA cần phân tích yêu cầu, xác định các điều kiện liên quan và suy luận những tình huống có khả năng làm chức năng hoạt động sai.
2. Bước 1: Đọc AC và xác định hành vi cốt lõi
Khi đọc một AC, đừng vội viết test case ngay. Trước tiên, hãy xác định bốn thành phần:
Actor: Ai thực hiện hành động?
Action: Người dùng thực hiện hành động gì?
Condition: Điều kiện nào cần được đáp ứng?
Expected Result: Hệ thống phải phản hồi như thế nào?
Ví dụ:
Given the Admin is on the Member List page, when the Admin clicks Select All, then all members in the list should be selected.
Có thể phân tích như sau:
| Thành phần | Nội dung |
|---|---|
| Actor | Admin |
| Action | Click Select All |
| Condition | Admin đang ở trang Member List |
| Expected Result | Tất cả thành viên thuộc phạm vi được chọn đều được chọn |
Từ một AC này, QA có thể bắt đầu đặt câu hỏi:
Danh sách có thành viên hay không?
Danh sách có bao nhiêu thành viên?
Nếu chỉ có một thành viên thì sao?
Nếu có nhiều trang thì Select All chọn tất cả bản ghi hay chỉ các bản ghi trên trang hiện tại?
Nếu một số thành viên đã được chọn trước đó thì sao?
Nếu Admin click Select All lần nữa thì trạng thái có thay đổi không?
Đây chính là bước chuyển từ yêu cầu nghiệp vụ sang tư duy kiểm thử.
Lưu ý: Những câu hỏi trên là các điểm cần làm rõ hoặc kiểm tra theo thiết kế sản phẩm. QA không nên tự quyết định hành vi khi AC chưa quy định rõ.
3. Bước 2: Tìm những từ khóa quan trọng trong AC
Một cách thực tế để phân tích AC là chú ý đến các từ mô tả điều kiện, giới hạn và hành vi.
Các từ khóa cần chú ý
| Từ khóa trong AC | Câu hỏi QA nên đặt ra |
|---|---|
| All / Every | Đã bao gồm tất cả đối tượng thuộc phạm vi chưa? |
| Only | Có trường hợp nào ngoài phạm vi vẫn thực hiện được hành động không? |
| Must / Should | Đây là yêu cầu bắt buộc hay hành vi mong muốn? |
| Cannot / Not allowed | Hệ thống có chặn đúng trường hợp không được phép không? |
| Empty / No data | Giao diện và logic xử lý khi không có dữ liệu thế nào? |
| Maximum / Minimum | Giá trị giới hạn và giá trị vượt giới hạn được xử lý ra sao? |
| When / If | Điều kiện kích hoạt có được kiểm tra đầy đủ không? |
| Before / After | Thứ tự thao tác có ảnh hưởng đến kết quả không? |
| Automatically | Hệ thống tự cập nhật trong những điều kiện nào? |
Ví dụ, nếu AC ghi:
The system should display an error message when the email is invalid.
QA không nên chỉ kiểm tra một email sai định dạng. Cần xem xét các nhóm đầu vào khác nhau như thiếu @, thiếu domain, chứa khoảng trắng hoặc bỏ trống email.
Tuy nhiên, những trường hợp nào được coi là không hợp lệ phải dựa trên quy tắc validation đã thống nhất, tránh tự tạo ra kỳ vọng không phù hợp với yêu cầu.
4. Bước 3: Áp dụng các kỹ thuật thiết kế Test Case
Sau khi hiểu AC, QA có thể sử dụng các kỹ thuật thiết kế kiểm thử để xây dựng bộ test có hệ thống.
4.1. Positive và Negative Testing
Positive Testing kiểm tra hệ thống khi đầu vào và điều kiện hợp lệ.
Negative Testing kiểm tra cách hệ thống xử lý đầu vào không hợp lệ hoặc hành động không được phép.
Ví dụ với chức năng tạo tài khoản:
Positive: Nhập đầy đủ thông tin hợp lệ và tạo tài khoản thành công.
Negative: Bỏ trống email, nhập email sai định dạng hoặc gửi request thiếu trường bắt buộc.
Security negative: Người không có quyền quản trị cố gắng tạo tài khoản bằng cách gọi API trực tiếp.
Đừng chỉ kiểm tra liệu chức năng có hoạt động trong trường hợp lý tưởng. Hãy xác minh hệ thống phản ứng đúng khi điều kiện không được đáp ứng.
4.2. Boundary Value Analysis — Phân tích giá trị biên
Khi AC có giới hạn về số lượng, độ dài hoặc giá trị, hãy kiểm tra quanh ranh giới.
Ví dụ, trường Password yêu cầu độ dài từ 8 đến 20 ký tự.
| Độ dài | Mục đích |
|---|---|
| 7 | Dưới giới hạn tối thiểu |
| 8 | Tại giới hạn tối thiểu |
| 9 | Ngay trên giới hạn tối thiểu |
| 19 | Ngay dưới giới hạn tối đa |
| 20 | Tại giới hạn tối đa |
| 21 | Vượt giới hạn tối đa |
Các giá trị này giúp phát hiện lỗi như dùng sai toán tử điều kiện hoặc xử lý sai giới hạn.
4.3. Equivalence Partitioning — Phân vùng tương đương
Thay vì kiểm tra mọi giá trị có thể nhập, QA chia đầu vào thành những nhóm được kỳ vọng có cách xử lý tương tự.
Ví dụ với trường số lượng vé:
Giá trị hợp lệ: số nguyên dương trong giới hạn cho phép.
Giá trị không hợp lệ: số âm.
Giá trị không hợp lệ: số 0, nếu nghiệp vụ yêu cầu ít nhất một vé.
Giá trị không hợp lệ: số thập phân, chuỗi hoặc giá trị không được hỗ trợ.
Sau đó, chọn các giá trị đại diện để kiểm thử từng nhóm.
4.4. State Transition Testing — Kiểm thử chuyển trạng thái
Kỹ thuật này đặc biệt hữu ích với các chức năng có trạng thái, chẳng hạn booking, payment, approval hoặc account activation.
Ví dụ, booking có các trạng thái Pending, Approved và Rejected.
QA cần xác minh:
Pending có thể chuyển sang Approved theo đúng điều kiện không?
Pending có thể chuyển sang Rejected không?
Booking đã Rejected có được phép Approved trở lại không?
Người dùng không có quyền có thể thay đổi trạng thái không?
Hai thao tác đồng thời có tạo ra trạng thái không nhất quán không?
Không phải mọi chuyển đổi đều được phép. QA cần dựa trên state transition rules của hệ thống để xác định expected result.
4.5. Decision Table — Bảng quyết định
Khi kết quả phụ thuộc vào nhiều điều kiện, bảng quyết định giúp QA tránh bỏ sót tổ hợp quan trọng.
Ví dụ, một người dùng chỉ được truy cập trang quản trị khi tài khoản đang hoạt động và có quyền Admin.
| Tài khoản hoạt động? | Có quyền Admin? | Kết quả kỳ vọng |
|---|---|---|
| Có | Có | Cho phép truy cập |
| Có | Không | Từ chối truy cập |
| Không | Có | Từ chối theo chính sách tài khoản |
| Không | Không | Từ chối truy cập |
Bảng quyết định đặc biệt hữu ích khi kiểm thử phân quyền, điều kiện thanh toán, quy trình phê duyệt và các business rules kết hợp nhiều yếu tố.
5. Bước 4: Kiểm tra các tình huống dễ bị bỏ sót
Sau khi viết test case cho hành vi chính, hãy kiểm tra thêm các nhóm sau.
Dữ liệu
Danh sách rỗng.
Chỉ có một bản ghi.
Nhiều bản ghi.
Dữ liệu trùng lặp.
Dữ liệu không hợp lệ hoặc thiếu trường.
Dữ liệu ở giới hạn cho phép.
Trạng thái
Trạng thái ban đầu.
Trạng thái sau thao tác thành công.
Trạng thái sau thao tác thất bại.
Người dùng thực hiện thao tác nhiều lần.
Người dùng quay lại hoặc làm mới trang.
Người dùng và quyền truy cập
Người dùng đúng quyền.
Người dùng thiếu quyền.
Người dùng truy cập tài nguyên của người khác.
Người dùng có quyền thay đổi trong quá trình sử dụng.
Tích hợp và dữ liệu
API trả về lỗi.
Request bị timeout.
Dữ liệu được cập nhật ở backend nhưng UI không đồng bộ.
Người dùng gửi nhiều request liên tiếp.
Thao tác thất bại nhưng hệ thống vẫn tạo dữ liệu hoặc gửi thông báo ngoài dự kiến.
Không phải task nào cũng cần kiểm tra tất cả những trường hợp trên. QA nên chọn phạm vi phù hợp với Acceptance Criteria, thiết kế hệ thống và mức độ rủi ro.
6. Ví dụ thực tế: Phân tích AC cho chức năng Select All
Giả sử task có Acceptance Criteria:
When the Admin clicks Select All, all members in the current list should be selected.
Từ yêu cầu này, QA có thể xây dựng các test scenarios sau:
| ID | Test Scenario | Expected Result |
|---|---|---|
| TC-01 | Select All khi danh sách có nhiều thành viên | Tất cả thành viên thuộc phạm vi được chọn đều được chọn |
| TC-02 | Select All khi danh sách chỉ có một thành viên | Thành viên duy nhất được chọn |
| TC-03 | Select All khi danh sách rỗng | Không có thành viên nào được chọn; UI xử lý đúng trạng thái rỗng |
| TC-04 | Bỏ chọn một thành viên sau khi Select All | Chỉ thành viên được thao tác bị bỏ chọn; trạng thái Select All được cập nhật theo thiết kế |
| TC-05 | Bỏ chọn Select All sau khi đã chọn tất cả | Các lựa chọn được bỏ theo đúng phạm vi và quy tắc của hệ thống |
| TC-06 | Select All khi danh sách đã được lọc | Hành vi đúng với phạm vi dữ liệu mà yêu cầu xác định |
| TC-07 | Select All khi danh sách có phân trang | Phạm vi lựa chọn tuân theo quy tắc phân trang đã thống nhất |
| TC-08 | Thay đổi bộ lọc sau khi đã chọn thành viên | Các lựa chọn được giữ hoặc xóa theo quy tắc nghiệp vụ |
| TC-09 | Thao tác chọn và bỏ chọn liên tiếp | Trạng thái checkbox không bị sai lệch |
| TC-10 | Thử gọi API thực hiện hành động tiếp theo bằng tài khoản không đủ quyền | Server từ chối hành động trái quyền nếu endpoint được bảo vệ |
Một điểm cần lưu ý: AC ban đầu chỉ nói “current list”, chưa xác định rõ Select All áp dụng cho các bản ghi trên trang hiện tại, tất cả bản ghi sau khi lọc hay toàn bộ bản ghi trong hệ thống.
QA nên trao đổi với Product Owner hoặc Developer để thống nhất phạm vi này trước khi chốt Expected Result.
Một test case tốt không chỉ có bước thực hiện rõ ràng mà còn cần Expected Result có thể xác minh được.
7. Bước 5: Traceability — Đảm bảo mỗi AC đều được kiểm thử
Sau khi hoàn thành bộ test case, QA nên đối chiếu lại từng AC để bảo đảm không có yêu cầu nào bị bỏ quên.
Có thể tạo một bảng Requirement Traceability Matrix (RTM) đơn giản:
| AC ID | Acceptance Criterion | Test Case IDs | Coverage |
|---|---|---|---|
| AC-01 | Select all members | TC-01, TC-02, TC-03 | Covered |
| AC-02 | Deselect an individual member | TC-04, TC-09 | Covered |
| AC-03 | Select all within filtered results | TC-06 | Needs clarification |
| AC-04 | Selection behavior across pages | TC-07 | Needs clarification |
RTM giúp QA và các thành viên trong nhóm nhìn thấy mối liên hệ giữa yêu cầu và test case.
Tuy nhiên, 100% AC được liên kết với test case không đồng nghĩa với 100% rủi ro đã được kiểm soát. Một AC vẫn có thể được kiểm thử chưa đủ sâu nếu chỉ có một test case cho luồng chính.
Vì vậy, QA cần kết hợp traceability với risk-based testing và review chất lượng của các test scenarios.
8. Checklist trước khi hoàn tất bộ Test Case
Trước khi chuyển sang thực thi kiểm thử, hãy tự hỏi:
- Tôi đã hiểu đúng mục tiêu nghiệp vụ của task chưa?
- Từng Acceptance Criterion đã được phân tích thành điều kiện kiểm thử chưa?
- Tôi đã xác định actor, action, condition và expected result chưa?
- Tôi đã bao gồm positive và negative scenarios phù hợp chưa?
- Tôi đã kiểm tra boundary values và các trạng thái đặc biệt chưa?
- Tôi đã xem xét quyền truy cập và phạm vi dữ liệu khi cần chưa?
- Tôi đã xác định những chức năng có thể bị ảnh hưởng bởi thay đổi chưa?
- Các điểm mơ hồ đã được làm rõ với người liên quan chưa?
- Mỗi AC đều có test case tương ứng trong RTM chưa?
- Expected Result có đủ rõ để xác định Pass hoặc Fail không?
Nếu có câu trả lời “Chưa” cho một mục quan trọng, hãy xem xét bổ sung test case hoặc làm rõ yêu cầu trước khi thực thi.
Kết luận
Đọc Acceptance Criteria là một kỹ năng quan trọng nhưng không đơn thuần là hiểu yêu cầu bằng ngôn ngữ tự nhiên. QA cần chuyển yêu cầu thành các điều kiện có thể kiểm chứng, dự đoán các tình huống thất bại và lựa chọn kỹ thuật thiết kế test phù hợp.
Một quy trình thực tế có thể tóm tắt như sau:
Understand the requirement → Identify conditions → Design test scenarios → Review edge cases → Map test cases to AC.
Đừng bắt đầu bằng câu hỏi “Tôi cần viết bao nhiêu test case?”. Hãy bắt đầu bằng câu hỏi:
“Những điều kiện nào có thể khiến chức năng hoạt động sai, và tôi cần bằng chứng gì để xác minh chúng?”
Khi tư duy theo cách này, QA sẽ xây dựng được bộ test có mục tiêu rõ ràng, giảm nguy cơ bỏ sót tình huống quan trọng và cung cấp cơ sở đáng tin cậy hơn cho quyết định release.
#QualityAssurance #SoftwareTesting #AcceptanceCriteria #TestCaseDesign #TestAnalysis #RegressionTesting #QAEngineer
