Đọc Requirement và viết Test Scenario: Kỹ năng cốt lõi cho tester trái ngành không code
2 ngày trước · 11 phút đọc
Mình từng test "theo cảm tính" và cái giá phải trả
Lần đầu nhận task test tính năng đăng nhập, mình nghĩ đơn giản: gõ đúng email-password thì vào được, gõ sai thì báo lỗi. Mình test hai trường hợp đó, tick xong, báo pass.
Ba ngày sau, khách hàng gọi về: hệ thống cho phép đăng nhập với password có toàn khoảng trắng. Mình không test edge case đó vì... không ai nói. Nhưng mà lý do đó không bào chữa được gì.
Vấn đề không phải mình lười. Mà mình không biết cách đọc requirement đúng cách để tự tìm ra những trường hợp cần test. Bài này mình chia sẻ đúng thứ mình ước gì có người chỉ từ đầu.
Đọc requirement kỹ từ đầu tiết kiệm hơn fix bug sau release rất nhiều
Bài này không yêu cầu bạn biết code. Chỉ cần biết đọc, biết đặt câu hỏi, và có tư duy logic - thứ mà người trái ngành hoàn toàn có thể học được.
Requirement là gì và tại sao tester phải đọc nó?
Requirement (yêu cầu phần mềm) là tài liệu mô tả phần mềm cần làm gì, hoạt động như thế nào, và trong hoàn cảnh nào. Tester đọc requirement không phải để hiểu dev cần code gì - mà để biết mình cần kiểm tra những gì.
Có hai loại requirement bạn sẽ hay gặp:
User Story - mô tả tính năng từ góc nhìn người dùng. Thường viết theo mẫu:
"Là [người dùng], mình muốn [làm gì], để [đạt được điều gì]."
Ví dụ: "Là khách hàng, mình muốn đăng nhập bằng email và password, để truy cập tài khoản của mình."
Acceptance Criteria (tiêu chí chấp nhận) - danh sách điều kiện cụ thể để tính năng đó được xem là "đạt". Thường đi kèm với User Story.
Ví dụ Acceptance Criteria cho tính năng đăng nhập:
- Hệ thống cho phép đăng nhập khi email và password đúng
- Hiển thị thông báo lỗi khi email không tồn tại
- Hiển thị thông báo lỗi khi password sai
- Khóa tài khoản sau 5 lần nhập sai liên tiếp
User Story cho biết "ai cần gì", Acceptance Criteria cho biết "test cái gì"
Tại sao tester phải đọc kỹ hai thứ này? Vì mỗi dòng trong Acceptance Criteria là ít nhất một test scenario. Nếu bạn bỏ qua dòng nào, bạn không test dòng đó. Đơn giản vậy thôi.
Thấy khó ở bước này là hoàn toàn bình thường. Lúc đầu mình cũng mất mấy ngày mới quen với cách đọc tài liệu kiểu này, vì nó khác hẳn văn bản thông thường.
Cách bóc tách requirement: công thức Input - Process - Output - Edge Case
Đây là kỹ thuật mình dùng mỗi khi nhận requirement mới. Thay vì đọc và test theo cảm tính, bạn phân tích tính năng theo 4 chiều:
Input - người dùng nhập/chọn/cung cấp gì cho hệ thống? Process - hệ thống xử lý như thế nào sau khi nhận input? Output - kết quả trả về cho người dùng là gì? Edge Case - những trường hợp ngoài lề, bất thường, hoặc giới hạn?
Bóc tách 4 chiều giúp không bỏ sót trường hợp test nào quan trọng
Áp dụng vào ví dụ tính năng đăng nhập:
| Chiều | Câu hỏi | Ví dụ |
|---|---|---|
| Input | Người dùng nhập gì? | Email, password |
| Process | Hệ thống kiểm tra gì? | Đúng email trong DB, đúng password hash |
| Output | Trả về gì khi thành công/thất bại? | Redirect dashboard / thông báo lỗi |
| Edge Case | Trường hợp bất thường? | Email không có @, password toàn khoảng trắng, tài khoản bị khóa |
Áp dụng vào thanh toán (payment):
| Chiều | Câu hỏi | Ví dụ |
|---|---|---|
| Input | Người dùng nhập gì? | Số thẻ, CVV, ngày hết hạn, số tiền |
| Process | Hệ thống làm gì? | Kết nối cổng thanh toán, kiểm tra số dư, trừ tiền |
| Output | Kết quả là gì? | Xác nhận thanh toán / thông báo lỗi cụ thể |
| Edge Case | Bất thường? | Số tiền = 0, số tiền âm, thẻ hết hạn, mất kết nối giữa chừng |
Áp dụng vào tìm kiếm (search):
| Chiều | Câu hỏi | Ví dụ |
|---|---|---|
| Input | Người dùng nhập gì? | Từ khóa tìm kiếm |
| Process | Hệ thống tìm thế nào? | Full-text search, filter theo danh mục |
| Output | Trả về gì? | Danh sách kết quả / thông báo "không tìm thấy" |
| Edge Case | Bất thường? | Ô tìm kiếm trống, từ khóa 1000 ký tự, ký tự đặc biệt như <script> |
Tại sao phải phân tích kỹ vậy? Vì bug thường nằm ở edge case, không phải happy path. Happy path là khi mọi thứ diễn ra đúng như kế hoạch. Edge case là khi người dùng làm thứ bạn không ngờ tới.
Cách viết test scenario từ user story
Test scenario (kịch bản kiểm thử) là mô tả ngắn gọn về một tình huống cụ thể cần kiểm tra. Nó trả lời câu hỏi: "Người dùng làm gì, hệ thống phản ứng như thế nào?"
Test scenario khác test case ở chỗ nào? Test scenario là bức tranh lớn, test case là từng bước chi tiết bên trong. Bạn viết test scenario trước để xác định "cần test bao nhiêu tình huống", sau đó mới viết test case chi tiết từng bước.
Công thức viết test scenario mình hay dùng:
[Hành động của người dùng] + [Dữ liệu/điều kiện] → [Kết quả mong đợi]
Mỗi dòng Acceptance Criteria tương ứng ít nhất một test scenario
Ví dụ từ User Story đăng nhập:
User Story: "Là khách hàng, mình muốn đăng nhập bằng email và password để truy cập tài khoản."
Acceptance Criteria:
- Đăng nhập thành công khi email và password đúng
- Hiển thị lỗi khi email không tồn tại
- Hiển thị lỗi khi password sai
- Khóa tài khoản sau 5 lần nhập sai
Test Scenarios tương ứng:
| # | Test Scenario | Loại |
|---|---|---|
| 1 | Đăng nhập với email và password hợp lệ → vào được dashboard | Happy path |
| 2 | Đăng nhập với email không tồn tại trong hệ thống → hiển thị lỗi phù hợp | Negative |
| 3 | Đăng nhập với email đúng nhưng password sai → hiển thị lỗi phù hợp | Negative |
| 4 | Nhập sai password 5 lần liên tiếp → tài khoản bị khóa | Edge case |
| 5 | Đăng nhập với email định dạng sai (thiếu @) → hệ thống từ chối | Edge case |
| 6 | Đăng nhập với password chỉ có khoảng trắng → hệ thống xử lý đúng | Edge case |
| 7 | Bỏ trống cả email và password rồi bấm đăng nhập → có thông báo báo lỗi | Edge case |
Lưu ý: scenario 5, 6, 7 không có trong Acceptance Criteria ban đầu. Mình tự thêm vào sau khi bóc tách Input - Edge Case. Đây chính là lý do bóc tách requirement quan trọng hơn đọc xong rồi test ngay.
Cách phát hiện requirement mơ hồ và hỏi lại đúng cách
Requirement mơ hồ là thứ sẽ làm khổ bạn nhất trong công việc tester. Ví dụ điển hình:
- "Hệ thống phải nhanh" - nhanh là bao nhiêu giây?
- "Hiển thị thông báo lỗi phù hợp" - phù hợp là nội dung gì?
- "Hỗ trợ nhiều ngôn ngữ" - bao nhiêu ngôn ngữ, ngôn ngữ nào?
- "Xử lý file lớn" - lớn là bao nhiêu MB?
Bạn test dựa trên requirement mơ hồ mà không hỏi lại, có hai kết quả xấu có thể xảy ra: hoặc bạn test sai thứ cần test, hoặc dev và tester không đồng ý với nhau về "đúng" là gì.
Requirement mơ hồ nếu không làm rõ sớm sẽ thành bom hẹn giờ trong dự án
Dấu hiệu nhận biết requirement mơ hồ
- Dùng từ "phù hợp", "nhanh", "dễ dùng", "thân thiện" mà không định nghĩa cụ thể
- Không nêu giới hạn (tối thiểu, tối đa, timeout)
- Không rõ ai là người thực hiện hành động (user hay admin?)
- Dùng "và/hoặc" không rõ ràng: "Hệ thống hiển thị lỗi và gửi email" - điều kiện nào kích hoạt?
Cách hỏi BA/PM để làm rõ
Đừng hỏi chung chung kiểu "requirement này chưa rõ". Hỏi cụ thể, kèm ví dụ, và đề xuất hiểu của bạn:
Template hỏi:
"Mình đọc requirement [tên tính năng], chỗ [trích dẫn câu mơ hồ]. Mình hiểu là [cách hiểu của bạn]. Hiểu vậy có đúng không? Hay ý là [cách hiểu khác]?"
Ví dụ thực tế:
"Mình đọc acceptance criteria cho tính năng tìm kiếm, chỗ 'hiển thị kết quả nhanh'. Mình hiểu là kết quả phải hiển thị trong vòng 2 giây. Hiểu vậy có đúng không? Hay team có con số cụ thể hơn?"
Cách hỏi này có hai lợi ích: bạn thể hiện đã đọc kỹ requirement, và BA/PM dễ xác nhận hoặc điều chỉnh hơn là phải giải thích từ đầu.
Thời điểm hỏi lý tưởng: Hỏi trước khi bắt đầu viết test case, không phải khi đã viết xong rồi mới phát hiện mơ hồ. Mình từng mất cả buổi chiều viết test case cho tính năng mà requirement chưa được confirm - kết quả phải viết lại một nửa.
Xác định phạm vi test: test cái gì, không test cái gì
Một trong những lỗi phổ biến của fresher tester là test quá rộng hoặc quá hẹp. Test quá rộng thì tốn thời gian vô ích, test quá hẹp thì bỏ sót bug quan trọng.
Phạm vi test (test scope) được xác định từ ba nguồn:
1. Tính năng mới hoặc thay đổi - đây là vùng phải test kỹ nhất. Dev vừa viết code mới, khả năng bug cao nhất ở đây.
2. Vùng bị ảnh hưởng - những tính năng cũ có liên quan đến thay đổi. Ví dụ: fix bug ở trang thanh toán → cần test lại giỏ hàng và trang xác nhận đơn hàng (vì chúng liên kết với nhau).
3. Tính năng không được đụng tới - thường không cần test lại trừ khi có lý do cụ thể.
Xác định đúng phạm vi test giúp phân bổ thời gian hợp lý cho từng vùng
Cách xác định vùng bị ảnh hưởng: hỏi dev "thay đổi này chạm vào module nào?". Dev biết code nên biết điều này. Bạn không cần hiểu code - chỉ cần hỏi đúng câu.
Một công cụ đơn giản: vẽ sơ đồ luồng người dùng (user flow) cho tính năng đang test. Ví dụ luồng mua hàng trên Shopee:
Tìm sản phẩm → Xem chi tiết → Thêm vào giỏ → Xem giỏ hàng → Nhập địa chỉ → Chọn phương thức thanh toán → Xác nhận đơn → Nhận thông báo
Nếu thay đổi nằm ở bước "Chọn phương thức thanh toán", bạn cần test kỹ bước đó và kiểm tra lại bước "Xác nhận đơn" và "Nhận thông báo" - vì chúng phụ thuộc vào kết quả thanh toán.
Bước trước đó như "Tìm sản phẩm" hay "Xem chi tiết" thường không bị ảnh hưởng - test nhanh qua (kiểm tra sanity - tức kiểm tra nhanh xem còn chạy không) là đủ.