Đọc requirement và viết test scenario: Kỹ năng cốt lõi cho tester trái ngành không code
một tháng trước · 10 phút đọc
Mình từng đọc requirement và... không hiểu gì cả
Lần đầu tiên được trao một tài liệu requirement, mình đọc xong vẫn không biết mình cần test cái gì. Toàn chữ là chữ, có chỗ mơ hồ đến mức dev và tester hiểu hai nghĩa khác nhau hoàn toàn. Kết quả? Mình viết test case sai hướng, phải làm lại từ đầu.
Bài này mình viết cho bạn nào đang bắt đầu - đặc biệt là bạn trái ngành, chưa quen với tài liệu IT. Không cần biết code. Chỉ cần biết đọc, biết đặt câu hỏi, và biết sắp xếp suy nghĩ logic.
Học xong bài này, bạn sẽ biết: requirement là gì, đọc thế nào cho đúng, phát hiện chỗ mơ hồ ở đâu, và viết test scenario từ requirement thực tế.
Từ tài liệu requirement đến test scenario - quy trình cần nắm vững
Requirement là gì và có mấy loại?
Requirement (yêu cầu phần mềm) là tài liệu mô tả hệ thống cần làm gì, hoạt động như thế nào, và đáp ứng điều kiện gì. Hiểu đơn giản: đây là "bản đặt hàng" của khách hàng gửi cho team kỹ thuật.
Có hai loại chính bạn sẽ gặp thường xuyên:
Functional requirement (yêu cầu chức năng) - mô tả hệ thống làm gì. Ví dụ: "Người dùng có thể đăng nhập bằng email và mật khẩu", "Hệ thống gửi email xác nhận sau khi đặt hàng thành công". Đây là loại bạn sẽ viết test case nhiều nhất.
Non-functional requirement (yêu cầu phi chức năng) - mô tả hệ thống hoạt động tốt đến mức nào. Ví dụ: "Trang đăng nhập tải trong vòng 2 giây", "Hệ thống hỗ trợ 1000 người dùng đồng thời", "Mật khẩu phải được mã hóa". Loại này liên quan đến performance, security, usability.
Functional = HỆ THỐNG LÀM GÌ, Non-functional = HỆ THỐNG TỐT ĐẾN MỨC NÀO
Ngoài ra bạn còn gặp User Story - cách viết requirement phổ biến trong các team Agile. Format chuẩn:
"Là [đối tượng người dùng], mình muốn [hành động], để [mục đích]."
Ví dụ: "Là khách hàng, mình muốn đặt lại mật khẩu qua email, để truy cập lại tài khoản khi quên mật khẩu."
Mỗi user story thường đi kèm acceptance criteria (tiêu chí chấp nhận) - điều kiện cụ thể để coi tính năng đó là "hoàn thành đúng". Đây là kim chỉ nam khi bạn viết test case.
Thấy nhiều khái niệm quá? Bình thường. Mình cũng mất vài tuần mới quen. Bạn không cần nhớ hết ngay, gặp đâu học đó là được.
Cách đọc requirement hiệu quả: 4 bước mình luôn làm
Đọc requirement không phải đọc như đọc truyện. Bạn cần đọc có mục tiêu - tức là đọc để tìm ra "mình cần test cái gì".
Mình luôn đi theo 4 bước sau:
Bước 1: Xác định đối tượng người dùng và luồng chính
Hỏi: Ai dùng tính năng này? Họ làm gì? Đi theo luồng nào? Với tính năng login, luồng chính là: nhập email + mật khẩu đúng → vào được trang chủ. Đây là happy path - kịch bản lý tưởng nhất.
Bước 2: Đọc kỹ acceptance criteria
Acceptance criteria là phần quan trọng nhất. Mỗi điều kiện trong đó là 1 test case tiềm năng. Ví dụ: "Hiển thị thông báo lỗi khi sai mật khẩu" → bạn cần có test case cho trường hợp này.
Bước 3: Tìm edge case (trường hợp biên)
Edge case là những tình huống bất thường mà requirement hay bỏ sót. Ví dụ: mật khẩu có ký tự đặc biệt (@, #, !), email chứa dấu cộng ([email protected]), copy-paste mật khẩu có khoảng trắng thừa ở đầu/cuối.
Edge case hay bị bỏ qua nhất - đây là chỗ bug thường trốn
Bước 4: Ghi lại câu hỏi ngay khi đọc
Bất cứ chỗ nào bạn thấy "mơ hồ" hay "chưa rõ" - ghi ngay ra. Đừng tự suy đoán. Mình sẽ nói cách hỏi clarification ở phần sau.
Mẹo nhỏ: Dùng bút màu (hoặc highlight trên Google Docs) để phân biệt: xanh = rõ ràng, vàng = cần hỏi thêm, đỏ = có khả năng conflict với chỗ khác. Làm quen thói quen này từ sớm sẽ tiết kiệm rất nhiều thời gian sau này.
Phát hiện requirement mơ hồ - đừng để bug đến từ hiểu sai
Requirement mơ hồ là nguồn gốc của rất nhiều bug. Không phải vì dev viết sai - mà vì cả dev lẫn tester hiểu theo hai nghĩa khác nhau, và không ai hỏi lại.
Mình từng gặp requirement ghi: "Hệ thống phải xử lý nhanh." Nhanh là bao nhiêu? 1 giây? 5 giây? 10 giây? Không ai biết. Dev cho là "nhanh" là 3 giây, khách hàng kỳ vọng dưới 1 giây. Bug từ đây mà ra.
Dấu hiệu nhận biết requirement mơ hồ:
- Từ ngữ chủ quan, không đo được: "nhanh", "dễ dùng", "đẹp", "hợp lý"
- Thiếu điều kiện cụ thể: "Hệ thống thông báo lỗi khi nhập sai" - nhập sai cái gì? Thông báo gì?
- Dùng "v.v.", "và các trường hợp khác": dấu hiệu viết tắt cho qua
- Mâu thuẫn giữa các phần: chỗ này nói cho phép login bằng tên đăng nhập, chỗ khác nói chỉ dùng email
- Thiếu hẳn trường hợp: requirement nói được làm gì nhưng không nói xảy ra lỗi thì sao
Requirement mơ hồ: tìm ra sớm hơn là sửa sau
Khi phát hiện requirement mơ hồ, bạn cần hỏi clarification (làm rõ). Cách hỏi hiệu quả:
- Trích dẫn đúng đoạn mơ hồ: "Trong phần 2.3, requirement ghi 'hệ thống phải phản hồi nhanh' - bạn có thể định nghĩa rõ 'nhanh' là bao nhiêu giây không?"
- Đề xuất hiểu của mình: "Mình hiểu là dưới 2 giây, đúng không?"
- Hỏi về trường hợp lỗi: "Nếu quá thời gian này, hệ thống xử lý thế nào?"
Hỏi rõ trước không phải làm phiền người khác. Đó là làm đúng việc của tester. Mình thích câu này: test case không kỹ = người khác không reproduce được = dev không fix được.
Viết test scenario: bước đệm quan trọng trước test case
Nhiều bạn mới hay nhảy thẳng từ requirement sang viết test case - và đó là lý do test case hay bị sót kịch bản.
Test scenario (tình huống kiểm thử) là mức trung gian: mô tả một tình huống tổng quát cần kiểm tra, chưa đi vào từng bước cụ thể. Coi nó như "đề mục" trước khi đi vào "chi tiết".
Ví dụ với tính năng đăng nhập:
| Test Scenario | Mô tả tóm tắt |
|---|---|
| TS-001 | Đăng nhập thành công với email và mật khẩu hợp lệ |
| TS-002 | Đăng nhập thất bại khi sai mật khẩu |
| TS-003 | Đăng nhập với email không tồn tại trong hệ thống |
| TS-004 | Đăng nhập với các trường bị bỏ trống |
| TS-005 | Đăng nhập với mật khẩu có ký tự đặc biệt |
| TS-006 | Hành động sau nhiều lần đăng nhập sai liên tiếp |
Test scenario = bản phác thảo trước khi viết test case chi tiết
Cách tạo test scenario từ requirement:
- Đọc từng acceptance criteria → mỗi điều kiện = 1 scenario
- Thêm happy path: luồng thành công hoàn toàn
- Thêm negative case: tất cả trường hợp đầu vào sai/thiếu
- Thêm edge case: giới hạn, ký tự đặc biệt, giá trị cực đại/cực tiểu
- Thêm business rule: quy tắc nghiệp vụ đặc biệt (ví dụ: khóa tài khoản sau 5 lần sai)
Một quy tắc mình hay nhắc: mỗi scenario phải trả lời được câu hỏi "Test cái gì?". Nếu scenario viết là "Kiểm tra đăng nhập" - quá chung. Phải rõ hơn: "Kiểm tra đăng nhập khi mật khẩu đúng nhưng email sai định dạng".
Từ test scenario xuống test case: ví dụ thực tế với login feature
Test scenario cho bạn bức tranh tổng. Test case là từng bức ảnh chi tiết trong đó.
Một test case đầy đủ gồm:
- Test Case ID: mã định danh
- Tên test case: mô tả ngắn
- Precondition: điều kiện trước khi test (ví dụ: "tài khoản đã tồn tại")
- Test steps: các bước thực hiện
- Test data: dữ liệu cụ thể dùng để test
- Expected result: kết quả mong đợi
Lấy TS-002 ở phần trên (đăng nhập thất bại khi sai mật khẩu), mình viết test case như sau:
Test Case ID: TC-002
Tên: Đăng nhập thất bại khi nhập sai mật khẩu
Precondition: Tài khoản [email protected] đã tồn tại trong hệ thống
Test Steps:
1. Mở trang đăng nhập
2. Nhập email: [email protected]
3. Nhập mật khẩu: wrongpassword123
4. Click nút "Đăng nhập"
Expected Result:
- Hệ thống KHÔNG cho phép đăng nhập
- Hiển thị thông báo: "Mật khẩu không đúng. Vui lòng thử lại."
- Người dùng vẫn ở trang đăng nhập
- Ô mật khẩu được xóa trắng, ô email giữ nguyên
Một test case tốt: người khác đọc là test được ngay, không cần hỏi lại
Bây giờ thử với payment feature - ví dụ phức tạp hơn một chút. Scenario: "Thanh toán thành công với thẻ hợp lệ."
Test Case ID: TC-PAY-001
Tên: Thanh toán thành công với thẻ Visa hợp lệ
Precondition:
- Người dùng đã đăng nhập
- Có ít nhất 1 sản phẩm trong giỏ hàng
- Tài khoản thẻ có đủ số dư
Test Steps:
1. Vào trang giỏ hàng
2. Click "Tiến hành thanh toán"
3. Nhập thông tin thẻ hợp lệ (số thẻ test: 4111 1111 1111 1111)
4. Nhập ngày hết hạn: 12/26
5. Nhập CVV: 123
6. Click "Xác nhận thanh toán"
Expected Result:
- Đơn hàng được tạo thành công
- Hiển thị trang xác nhận với mã đơn hàng
- Email xác nhận gửi đến hộp thư của người dùng
- Số dư giỏ hàng về 0
Lưu ý quan trọng: expected result phải đủ cụ thể để ai cũng biết pass hay fail. "Đăng nhập được" là không đủ. "Chuyển sang trang /dashboard, hiển thị tên người dùng ở góc phải" mới là đủ.