Đọ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
3 tháng trước · 8 phút đọc
Tại sao đọc requirement mà vẫn viết sai test scenario?
Mình nhớ lần đầu nhận tài liệu requirement cho tính năng đăng ký tài khoản. Đọc xong, mình nghĩ hiểu rồi, ngồi viết test scenario một mạch. Kết quả? Senior review và hỏi: "Bạn test luồng người dùng nhập email đã tồn tại chưa? Luồng mật khẩu không khớp nhau chưa?"
Mình nhìn lại tài liệu - thông tin đó có hết. Mình chỉ không đọc kỹ.
Đây là lỗi phổ biến nhất của tester mới, dù trái ngành hay học IT: đọc requirement theo kiểu đọc lướt, không phải đọc để test. Hai kiểu đọc này khác nhau hoàn toàn.
Bài này mình chia sẻ quy trình 5 bước mình dùng mỗi khi nhận requirement mới. Không cần biết code, chỉ cần tỉ mỉ và logic.
Đọc requirement lần đầu và đọc để test là hai việc hoàn toàn khác nhau
Bạn không cần background IT để làm tốt bước này. Cần sự kiên nhẫn và thói quen đặt câu hỏi đúng chỗ.
Bước 1: Đọc toàn bộ một lần, không ghi gì
Nghe có vẻ ngược đời, nhưng đây là bước quan trọng nhất.
Lần đọc đầu tiên, bạn chỉ cần hiểu bức tranh tổng thể: tính năng này làm gì, phục vụ ai, nằm ở đâu trong hệ thống. Đừng vội highlight, đừng vội ghi test case. Não bạn cần một lần chạy toàn bộ trước khi bắt đầu phân tích.
Sau khi đọc xong, tự trả lời 3 câu hỏi:
- Tính năng này dành cho ai? (user thông thường, admin, hay khách chưa đăng nhập?)
- Kết quả cuối cùng mong muốn là gì? (đăng ký thành công, thanh toán xong, tải file về...)
- Có tính năng nào khác liên quan không? (đăng nhập phụ thuộc vào đăng ký, giỏ hàng phụ thuộc vào tồn kho...)
3 câu hỏi này giúp bạn không bị lạc vào chi tiết trước khi hiểu toàn cảnh
Ví dụ thực tế: mình nhận requirement cho tính năng "Quên mật khẩu" của một app bán hàng. Đọc lần đầu, mình xác định được: dành cho user đã có tài khoản, kết quả là reset được mật khẩu qua email, và tính năng này liên quan đến màn hình đăng nhập.
Có vậy thôi. Đủ để bắt đầu bước 2.
Bước 2: Nhận diện các luồng chính (user flow)
Requirement thường mô tả tính năng theo dạng văn xuôi hoặc bullet points. Nhiệm vụ của bạn là chuyển chúng thành luồng hành động của người dùng.
Mình hay dùng cấu trúc: Khi [ai đó] làm [hành động], hệ thống phải [phản ứng gì].
Với mỗi tính năng, thường có ít nhất 3 loại luồng cần nhận diện:
| Loại luồng | Mô tả | Ví dụ (đăng nhập) |
|---|---|---|
| Happy path | Mọi thứ đúng, thành công | Nhập email+pass đúng → vào dashboard |
| Error path | Nhập sai, thiếu, không hợp lệ | Email sai format → báo lỗi |
| Edge case | Trường hợp giới hạn, hiếm gặp | Tài khoản bị khóa, hết phiên đăng nhập |
Lưu ý: Requirement thường chỉ mô tả happy path. Error path và edge case bạn phải tự suy ra. Đây là chỗ tester giỏi khác tester trung bình.
Happy path chỉ là một phần nhỏ - error path và edge case mới là nơi bug ẩn náu
Thực hành ngay: lấy requirement tính năng bất kỳ bạn đang có, thử liệt kê 3 luồng theo bảng trên. Mình đảm bảo bạn sẽ tìm thấy ít nhất 1-2 luồng requirement không đề cập.
Bước 3: Đặt tiêu chí chấp nhận (acceptance criteria)
Tiêu chí chấp nhận - hay gọi là acceptance criteria - là ranh giới để bạn phán quyết: tính năng này "đạt" hay "không đạt".
Nếu requirement không có phần này (nhiều tài liệu thực tế thiếu), bạn phải tự xây dựng. Công thức đơn giản nhất:
GIVEN [bối cảnh] - WHEN [hành động] - THEN [kết quả mong đợi]
Ví dụ cụ thể cho tính năng đăng nhập:
- GIVEN user đã có tài khoản, WHEN nhập đúng email và mật khẩu, THEN chuyển hướng đến trang dashboard trong vòng 3 giây
- GIVEN user nhập sai mật khẩu 5 lần liên tiếp, WHEN click đăng nhập lần thứ 5, THEN tài khoản bị khóa 30 phút và hiển thị thông báo rõ ràng
Công thức GIVEN-WHEN-THEN giúp test case rõ ràng, ai cũng reproduce được
Tại sao cần bước này? Vì nếu không có tiêu chí rõ, bạn và dev sẽ tranh luận "lỗi" hay "feature" mãi không xong. Mình từng mất 2 buổi họp vì thiếu acceptance criteria cho một nút bấm. Từ đó mình không bao giờ bỏ qua bước này nữa.
Không cần viết dài. 3-5 criteria cho mỗi luồng là đủ để bắt đầu test.
Bước 4: Ghi chú test data cần chuẩn bị
Bước này nhiều bạn mới hay bỏ qua nhất. Kết quả là ngồi vào test mới loạn vì không biết dùng dữ liệu gì.
Test data là dữ liệu đầu vào bạn sẽ dùng khi chạy test. Cần chuẩn bị trước, không phải đến lúc test mới nghĩ.
Với mỗi tính năng, liệt kê các loại data theo nhóm:
- Data hợp lệ: email đúng format, mật khẩu đủ 8 ký tự, số điện thoại 10 số...
- Data không hợp lệ: email thiếu @, mật khẩu 3 ký tự, số âm, chuỗi rỗng...
- Data biên giới (boundary): đúng 8 ký tự (min), đúng 50 ký tự (max), 0, -1, số rất lớn...
- Data đặc biệt: ký tự tiếng Việt có dấu, emoji, ký tự đặc biệt như
<>"', khoảng trắng đầu/cuối...
Chuẩn bị test data trước giúp bạn không bỏ sót boundary case khi đang test
Ví dụ thực tế: mình test trường nhập tên người dùng, tưởng chỉ cần test "Nguyễn Văn A" là xong. Sau thêm "Nguyễn Văn Á" (chữ Á hoa), "nguyễn văn a" (toàn thường), "NGUYỄN VĂN A" (toàn hoa), khoảng trắng đầu " Nguyễn", và ký tự đặc biệt "Nguyễn <script>" - phát hiện 3 bug. Tất cả từ một trường tên tưởng chừng đơn giản.
Download template bên dưới để có sẵn bảng ghi chú test data theo 4 nhóm: Tải template ghi chú test data
Bước 5: Kiểm tra lại logic trước khi viết test case
Sau 4 bước trên, bạn có: bức tranh tổng thể, 3 luồng, acceptance criteria, và test data. Nhưng đừng vội viết test case ngay.
Dành 15 phút đọc lại toàn bộ và tự hỏi:
1. Luồng có mâu thuẫn không? Ví dụ: requirement nói "khóa tài khoản sau 3 lần sai", nhưng chỗ khác lại nói "cảnh báo sau 5 lần sai". Con số nào đúng?
2. Có điều kiện nào chưa xác định? Ví dụ: "hiển thị thông báo lỗi" - nhưng thông báo đó nói gì? Tiếng Việt hay tiếng Anh? Ở vị trí nào trên màn hình?
3. Luồng có đầy đủ từ đầu đến cuối không? Thử trace từng luồng: User bắt đầu từ đâu, làm gì, hệ thống phản hồi gì, kết thúc ở đâu. Nếu trace mà bị kẹt ở bước nào - requirement thiếu thông tin.
15 phút kiểm tra logic giúp tránh viết test case sai hướng rồi phải làm lại toàn bộ
Mọi điểm mơ hồ cần ghi ra và hỏi BA (Business Analyst) hoặc PM trước khi test. Đừng tự đoán. Tự đoán sai = test sai = bug lọt production.
Sau bước này, bạn mới bắt đầu viết test case. Lúc này viết sẽ nhanh gấp đôi vì đầu đã rõ ràng.