Đọc Requirement và Viết Test Scenario: Kỹ năng cốt lõi cho Tester trái ngành không cần code (2026)
3 tháng trước · 12 phút đọc
Requirement là gì và tại sao tester cần đọc kỹ?
Mình nhớ lần đầu nhận một file requirement dài 30 trang. Lướt qua rồi tự tin viết test case. Kết quả? Bug nổ production vì mình bỏ sót một điều kiện nhỏ ở trang 17 - "Nếu người dùng chưa xác minh email, không cho phép đặt hàng." Dev đã làm đúng theo spec. Mình đã không test đủ vì không đọc kỹ.
Requirement (hay còn gọi là đặc tả yêu cầu) là tài liệu mô tả hệ thống cần làm gì, hoạt động như thế nào, và người dùng tương tác ra sao. Đây là "bản hợp đồng" giữa khách hàng, BA (Business Analyst), dev và tester.
Requirement là điểm khởi đầu của mọi test case
Với tester, requirement không phải thứ "đọc cho biết". Đây là nguyên liệu chính để viết test scenario và test case. Đọc sót một dòng = bỏ sót một nhóm test case = bug lọt qua.
Có ba loại requirement bạn hay gặp khi đi làm:
- BRD (Business Requirement Document): Mô tả nghiệp vụ, mục tiêu kinh doanh. Thường do BA viết, khá dài và trừu tượng.
- FRS/SRS (Functional/Software Requirement Specification): Chi tiết hơn, mô tả từng tính năng, luồng xử lý, điều kiện. Đây là loại bạn dùng nhiều nhất.
- User Story: Phổ biến trong team Agile. Format ngắn gọn: "Với tư cách là [ai], tôi muốn [làm gì], để [đạt mục đích gì]."
Bạn không cần code để hiểu requirement. Chỉ cần đọc chậm, đọc có mục đích, và biết đặt câu hỏi đúng chỗ.
Cách đọc requirement như một tester thực thụ
Đọc requirement như tester khác hoàn toàn đọc như người dùng thông thường. Người dùng đọc để hiểu tính năng. Tester đọc để tìm lỗ hổng, điều kiện biên, và những gì chưa được định nghĩa rõ.
Có một framework đơn giản mình hay dùng khi đọc requirement, gọi là "5 câu hỏi vàng":
1. Happy path là gì? Luồng chính - khi mọi thứ diễn ra đúng như mong đợi. Ví dụ: Người dùng nhập đúng email và password → đăng nhập thành công.
2. Điều kiện nào khiến luồng thất bại? Sai password, tài khoản bị khóa, email không tồn tại, hết phiên đăng nhập... Mỗi điều kiện là một test scenario riêng.
3. Có giới hạn nào không? Số ký tự tối thiểu/tối đa, giới hạn số lần thử, thời gian timeout. Đây là nơi hay xuất hiện boundary testing (kiểm thử biên).
4. Ai dùng tính năng này? User thường, admin, khách vãng lai? Mỗi vai trò có thể có quyền và luồng khác nhau.
5. Cái gì chưa được viết? Requirement không bao giờ hoàn chỉnh 100%. Những khoảng trống này gọi là "ambiguous requirement" - yêu cầu mơ hồ. Việc của tester là phát hiện và hỏi BA/dev làm rõ trước khi test.
Tìm "khoảng trống" trong requirement quan trọng hơn đọc cái đã viết
Thực hành ngay: Lấy user story sau và áp dụng 5 câu hỏi:
"Với tư cách là người mua hàng, tôi muốn thêm sản phẩm vào giỏ hàng, để dễ dàng thanh toán sau."
Requirement này thiếu: Sản phẩm hết hàng thì sao? Có giới hạn số lượng trong giỏ không? Khách chưa đăng nhập có thêm vào giỏ được không? Mỗi câu hỏi đó = 1-2 test scenario bạn cần viết.
Test scenario là gì và khác test case như thế nào?
Nhiều bạn mới vào nghề hay nhầm lẫn giữa test scenario và test case. Hiểu đúng sự khác biệt sẽ giúp bạn làm việc nhanh hơn và không viết thừa.
Test scenario là mô tả tình huống cần kiểm thử ở mức tổng quan, không đi vào từng bước chi tiết. Ví dụ: "Kiểm tra luồng đăng nhập với tài khoản hợp lệ."
Test case là mô tả chi tiết từng bước thực hiện, dữ liệu đầu vào, và kết quả mong đợi. Ví dụ cùng tình huống trên: Bước 1 - mở trang /login, Bước 2 - nhập email [email protected], Bước 3 - nhập password Test@123, Bước 4 - click nút Đăng nhập, Expected result - chuyển hướng về /dashboard.
| Test Scenario | Test Case | |
|---|---|---|
| Mức độ | Tổng quan | Chi tiết |
| Dùng khi | Lập kế hoạch, ước lượng | Thực thi test |
| Viết trước | ✓ | Sau scenario |
| Thời gian viết | Nhanh hơn | Lâu hơn |
Viết scenario trước giúp bao quát toàn bộ trước khi đi vào chi tiết
Quy trình thực tế: Từ requirement → viết hết test scenario → review với BA/dev → mới viết test case từng scenario.
Lý do phải làm theo thứ tự này? Nếu viết test case ngay mà không có scenario tổng quan, bạn dễ mất cả ngày viết chi tiết cho 1 luồng rồi phát hiện còn 5 luồng khác chưa bao giờ được đề cập. Test scenario là bản đồ, test case là đường đi chi tiết.
Cách viết test scenario từ requirement - 4 bước thực hành
Bây giờ đến phần thực chiến. Mình lấy ví dụ với tính năng Đăng ký tài khoản của một app thương mại điện tử để minh họa từng bước.
Requirement mẫu:
Người dùng có thể đăng ký tài khoản bằng email. Email phải hợp lệ và chưa được đăng ký. Password tối thiểu 8 ký tự, gồm ít nhất 1 chữ hoa và 1 số. Sau khi đăng ký thành công, hệ thống gửi email xác minh.
Bước 1: Xác định các luồng chính (main flows)
Đọc requirement và liệt kê: luồng thành công (happy path) và các luồng thất bại rõ ràng.
- Đăng ký thành công với thông tin hợp lệ
- Đăng ký thất bại vì email không đúng format
- Đăng ký thất bại vì email đã tồn tại
- Đăng ký thất bại vì password không đủ điều kiện
Bước 2: Tìm điều kiện biên (boundary conditions)
Nhìn vào các con số và giới hạn trong requirement: "tối thiểu 8 ký tự, ít nhất 1 chữ hoa và 1 số."
- Password đúng 8 ký tự (boundary)
- Password 7 ký tự (dưới boundary)
- Password đủ ký tự nhưng thiếu chữ hoa
- Password đủ ký tự nhưng thiếu số
Bước 3: Tìm khoảng trống trong requirement
Requirement trên chưa nói rõ:
- Trường email và password có bắt buộc điền không? (empty field)
- Giao diện hiển thị lỗi như thế nào?
- Email xác minh đến trong bao lâu?
- Điều gì xảy ra nếu người dùng đăng ký nhưng chưa xác minh email?
Ghi lại những câu hỏi này và hỏi BA trước khi viết test case.
Bước 4: Tổ chức thành test scenario
Gom tất cả lại thành danh sách có tên rõ ràng:
TS-001: Đăng ký thành công với email hợp lệ và password đủ điều kiện
TS-002: Đăng ký thất bại khi email không đúng format
TS-003: Đăng ký thất bại khi email đã tồn tại trong hệ thống
TS-004: Đăng ký thất bại khi password ít hơn 8 ký tự
TS-005: Đăng ký thất bại khi password thiếu chữ hoa
TS-006: Đăng ký thất bại khi password thiếu số
TS-007: Kiểm tra gửi email xác minh sau đăng ký thành công
TS-008: Kiểm tra hành vi khi để trống trường email
TS-009: Kiểm tra hành vi khi để trống trường password
Từ 1 requirement ngắn có thể ra 9 test scenario - đừng bỏ sót
Thấy không? Từ một đoạn requirement 3 câu, mình tạo ra 9 test scenario. Nếu không đọc kỹ và không áp dụng 4 bước này, bạn dễ chỉ viết TS-001 rồi nghĩ "xong". Bug vẫn nằm ở TS-004, TS-005 chờ nổ production.
Tải template test scenario để thực hành ngay: Tải template test scenario (HTML)
Lỗi phổ biến nhất khi viết test scenario - và cách tránh
Mình quan sát nhiều bạn mới học, có một số lỗi lặp đi lặp lại. Biết trước sẽ giúp bạn tránh từ đầu.
Lỗi 1: Chỉ viết happy path
Sai lầm kinh điển. Bạn chỉ test "mọi thứ đúng" rồi báo pass. Thực tế phần lớn bug phát sinh từ các luồng negative (sai dữ liệu, lỗi kết nối, edge case). Mỗi tính năng phải có ít nhất 2-3 scenario negative.
Lỗi 2: Scenario quá chung chung
Viết "Kiểm tra chức năng đăng nhập" không có giá trị vì không ai biết bạn đang test cái gì cụ thể. Scenario phải đủ cụ thể để người khác đọc hiểu ngay không cần hỏi thêm.
❌ Sai: "Test tính năng giỏ hàng"
✅ Đúng: "Kiểm tra thêm sản phẩm vào giỏ khi sản phẩm còn hàng và chưa đăng nhập"
Lỗi 3: Bỏ qua điều kiện biên (boundary)
Input tối thiểu, tối đa, đúng bằng giới hạn - đây là nơi bug hay trốn nhất. Một form nhập tên yêu cầu "2-50 ký tự" cần test: 1 ký tự (dưới min), 2 ký tự (đúng min), 50 ký tự (đúng max), 51 ký tự (vượt max).
Lỗi 4: Không cập nhật khi requirement thay đổi
Dev sprint 2, BA thêm điều kiện mới vào requirement. Bạn không chú ý, tiếp tục dùng scenario cũ. Kết quả: bỏ sót tính năng mới hoàn toàn. Mình khuyên bạn tạo thói quen so sánh requirement mới và cũ mỗi khi có cập nhật.
Scenario quá rộng = không ai biết bạn đang test cái gì
Thấy khó ở phần boundary testing bình thường. Mình cũng mất vài tuần mới quen tư duy tìm điều kiện biên. Cách nhanh nhất là luyện tập với các form nhỏ hàng ngày - form đăng ký, form tìm kiếm, form thanh toán.
Công cụ và template để bắt đầu ngay hôm nay
Bạn không cần tool xịn để viết test scenario. Quan trọng là bắt đầu.
Mình thấy phần lớn team dùng 3 công cụ phổ biến nhất:
Google Sheets / Excel: Đơn giản, ai cũng dùng được. Tạo các cột: ID, Tên scenario, Loại (happy/negative/boundary), Module, Độ ưu tiên (High/Medium/Low), Ghi chú. Phù hợp khi mới bắt đầu và team nhỏ.
Jira + Zephyr/Xray: Công cụ quản lý test chuyên nghiệp. Thường dùng ở công ty lớn. Đừng lo nếu chưa biết - học khi đi làm cũng kịp. Interface có hướng dẫn, không phức tạp hơn Google Sheets nhiều.
TestRail: Phần mềm test management phổ biến. Có free tier cho team nhỏ. Giao diện rõ ràng, phù hợp khi muốn thử trước khi đi làm.
Bắt đầu bằng Google Sheets, nâng cấp lên tool chuyên nghiệp khi cần
Mình hay khuyên bạn mới: bắt đầu bằng Google Sheets. Lý do đơn giản - khi bạn còn đang học tư duy tester, đừng tốn thời gian học tool. Tool học 1 ngày là xong, tư duy cần vài tuần.
Checklists hữu ích khi viết test scenario: Tải checklist viết test scenario (HTML)
Bước tiếp theo sau khi bạn nắm vững test scenario là học cách viết test case chi tiết từ từng scenario - đặc biệt là cách chọn test data hợp lý và viết expected result không mơ hồ. Mình sẽ cover phần đó trong bài tiếp theo.
Nếu bạn đang tìm hiểu về IT nói chung trước khi đi sâu vào testing, khóa Kiến Thức Nhập Môn IT của F8 là điểm khởi đầu tốt để hiểu bức tranh tổng thể ngành.
Comment bên dưới tình huống requirement bạn đang gặp khó - mình giải đáp từng bạn. Chúc bạn test kỹ, bug không lọt!