Chương 04 Cơ Bản
Phân Tích Yêu Cầu
Kỹ năng đọc spec, phát hiện gap, tạo RTM và chuyển AC thành test cases — nền tảng để test đúng thứ cần test.
📖 Đọc & Phân Tích Requirement Required
Khi nhận requirement (BRS, SRS, User Story, Figma design), QA cần evaluate theo 5 tiêu chí CCCTF:
- CompletenessRequirement có đủ thông tin không? Thiếu gì? Ví dụ: "User có thể upload avatar" — thiếu: kích thước tối đa? Định dạng cho phép? Kích thước hiển thị?
- ClarityCó từ ngữ mơ hồ không? "Fast" = bao nhiêu giây? "Appropriate error message" = message nào? "Recent" = 7 ngày hay 30 ngày?
- ConsistencyCó mâu thuẫn với requirement khác không? Ví dụ: REQ-01 nói "password min 6 chars" nhưng REQ-05 nói "min 8 chars".
- TestabilityCó thể verify được không? "System should be user-friendly" → không testable. "Form submission < 2 seconds" → testable.
- FeasibilityCó khả thi về mặt kỹ thuật và thời gian không? QA cần raise concern sớm nếu requirement có vẻ impossible.
| Requirement (Xấu) | Vấn đề | Requirement (Tốt) |
|---|---|---|
| System should load quickly | Không testable, không cụ thể | Page load time < 2 seconds (P90) under normal load |
| User-friendly interface | Chủ quan, không measurable | New user completes registration in < 3 minutes without help |
| System should handle errors | Quá chung chung | All form validation errors display inline with specific fix guidance |
| Support multiple languages | Không xác định ngôn ngữ nào | Support English (US), Spanish (MX), French (CA) at launch |
🗂️ RTM — Tạo Từ Scratch
Requirement Traceability Matrix là bảng đảm bảo mọi requirement đều có test case cover. Không có RTM → không biết coverage gap ở đâu.
- Thu thập Requirements: List tất cả requirements từ BRS/SRS/User Stories với unique ID (REQ-001, REQ-002...)
- Tạo cột Test Case: Mỗi requirement link đến 1+ test case IDs. Một requirement có thể cần nhiều TC (positive + negative + edge).
- Điền Test Execution Status: Khi chạy test, update Pass/Fail/Blocked/Not Run cho từng TC
- Xác định Coverage Status: Covered (có TC), Partially Covered (một số case chưa có TC), Not Covered (chưa có TC nào)
- Maintain liên tục: Khi requirement thay đổi → update RTM ngay. RTM cũ = giá trị âm.
| Req ID | Requirement | Priority | Test Case IDs | Status | Coverage |
|---|---|---|---|---|---|
| REQ-001 | User đăng nhập bằng email/password | P1 | TC_LOGIN_001, 002, 003 | Pass/Pass/Fail | Partial |
| REQ-002 | Lock account sau 5 lần sai password | P1 | TC_LOGIN_004 | Pass | Covered |
| REQ-003 | Remember me functionality | P2 | TC_LOGIN_005, 006 | Not Run | Covered |
| REQ-004 | Single Sign-On với Google | P2 | — | — | Not Covered ⚠️ |
📌 RTM Best Practice
Luôn tạo RTM từ đầu dự án, không phải sau khi viết test case xong. Approach đúng: Requirement → Test Condition → Test Case → Test Script. RTM giúp bạn justify mọi test case bạn viết và mọi test case bạn KHÔNG viết.
📝 User Story & Acceptance Criteria
Trong Agile, requirement viết dạng User Story với AC (Acceptance Criteria) theo format Given/When/Then:
📋 Ví dụ User Story
Story: As a registered user, I want to reset my password via email so that I can access my account when I forget my password.AC 1: Given a user on the login page, When they click "Forgot Password" and enter a valid email, Then they receive a reset link within 5 minutes.
AC 2: Given a reset link is clicked, When the link is valid (not expired), Then the user can set a new password.
AC 3: Given a reset link is clicked, When the link has expired (> 24 hours), Then the user sees an error and is prompted to request a new link.
Từ AC → Test Cases (QA phải bổ sung thêm):
- AC 1 → TC: Valid email (registered) → receive link | Invalid email (not registered) → what happens? | Email field empty → validation error | Multiple requests → only last link works?
- AC 2 → TC: Click valid link → can set new password | New password = old password → allowed? | Password meet policy? | Link used twice → second use should fail
- AC 3 → TC: Click expired link (25h old) → error message correct | Click link after already used → error message correct
- QA adds: What if user requests reset, doesn't use it, requests again? | Reset link in different browser/device? | Reset while session is active on another device?
🏆 Senior Insight
Junior QA convert AC thành test case. Senior QA đặt câu hỏi về những gì AC KHÔNG đề cập — những edge case, security implications, và integration points. Câu hỏi tốt trong 3 Amigos tiết kiệm hàng giờ debugging sau này.
❓ Xử Lý Requirement Mơ Hồ
- IdentifyĐánh dấu tất cả từ ngữ mơ hồ: "should," "appropriate," "fast," "easy," "many," "some." Những từ này = unclear requirement.
- Document AssumptionsNếu chưa clarify được, document assumption của bạn: "Assumption: 'fast' means < 3 seconds. Please confirm." Protect yourself.
- Ask the Right PeopleProduct Owner / BA cho business logic. Designer / UX cho UI behavior. Developer cho technical constraints. Don't guess.
- Frame Questions WellThay vì "What does 'fast' mean?" → "In REQ-012, 'fast response' — can we define this as < 2 seconds for P90 requests under 1000 concurrent users?"
- Log DecisionsMọi clarification phải được document — trong JIRA comment, Confluence, email. Không có "verbal agreement" trong QA.
🔍 Gap Analysis
Coverage gap = requirement có nhưng không có test case. Gap analysis giúp phát hiện và prioritize gaps.
- Functional gaps: Requirement chưa có TC nào — highest priority, phải cover trước release
- Negative test gaps: Chỉ có positive test, thiếu negative/error cases — common issue với junior QA
- Integration gaps: Test từng module riêng lẻ nhưng chưa test kết hợp — E2E flow gaps
- Non-functional gaps: Không có performance, security, accessibility test cases — thường bị bỏ qua
- Regression gaps: Test cases cũ không được update khi requirement thay đổi — obsolete tests
✏️ Bài Tập
📝 Bài Tập: Phân Tích Requirements
Phân tích requirement sau và trả lời các câu hỏi:
"The system should load quickly. Users can upload files. Admin users can manage other users. The system should be secure."
- Identify tất cả vấn đề trong 4 requirements trên (mỗi cái có ít nhất 2 vấn đề)
- Rewrite từng requirement thành dạng testable, specific
- Viết 3 câu hỏi clarification cho requirement "Users can upload files"
- Tạo RTM skeleton cho 4 requirements (chỉ cần điền cột Req ID, Requirement, Coverage Status)
💼 Interview Q&A
What do you do when you receive unclear requirements?
First, I document all ambiguous points — specific words or scenarios that are unclear. Then I schedule a quick call or 3 Amigos meeting with the BA/PO and dev to clarify. I frame questions specifically: instead of "what does X mean?", I say "I'm interpreting X as Y — is that correct?" This saves everyone time. All clarifications get documented in JIRA or Confluence so we have a reference. If clarification can't happen quickly, I document my assumptions and proceed, flagging the risk.
What is a Requirement Traceability Matrix and why is it important?
RTM is a table linking requirements to test cases, and tracking execution status. It's important for three reasons: (1) Coverage assurance — every requirement has at least one test case, no gaps; (2) Impact analysis — when a requirement changes, you know exactly which test cases to update; (3) Audit trail — you can show stakeholders exactly what was tested and what wasn't. Without RTM, you're essentially guessing about coverage.