Đọc requirement và viết test scenario: Kỹ năng cốt lõi của tester trái ngành
4 tháng trước · 12 phút đọc
Tại sao đọc requirement là kỹ năng số 1 của tester?
Mình nhớ lần đầu nhận tài liệu requirement để viết test case, cứ nghĩ đọc xong là hiểu ngay. Kết quả? Viết được 5 test case nhưng bỏ sót hoàn toàn luồng thanh toán thất bại. Bug nổ production, dev quay lại hỏi "bạn có test case cho trường hợp này không?". Câu trả lời là... không.
Vấn đề không phải là mình không biết viết test case. Vấn đề là mình không biết đọc requirement đúng cách.
Với tester trái ngành, đây là điểm dễ vấp nhất. Bạn đọc xong, hiểu đại ý, rồi bắt tay viết test case luôn. Bỏ qua bước quan trọng ở giữa: phân tích và chuyển thành test scenario trước.
Đọc requirement kỹ là bước quyết định chất lượng toàn bộ quá trình test
Test scenario (kịch bản kiểm thử) là bước trung gian giữa requirement và test case. Nó trả lời câu hỏi "cần test cái gì" trước khi đi vào "test như thế nào". Bỏ bước này giống như nấu ăn mà không coi công thức, chỉ đoán nguyên liệu - có thể ra được món ăn, nhưng thiếu sót rất nhiều.
User story là gì và đọc như thế nào?
User story là cách viết requirement phổ biến nhất trong các team phần mềm hiện đại. Nó có cấu trúc chuẩn:
Là [đối tượng], tôi muốn [làm gì], để [mục đích gì].
Ví dụ thực tế:
"Là người dùng, tôi muốn đăng nhập bằng email và mật khẩu, để vào được trang quản lý đơn hàng của mình."
Nhìn câu này, nhiều bạn mới chỉ thấy một thứ: đăng nhập. Nhưng khi đọc đúng cách, bạn phải tách ra được 3 câu hỏi:
Đối tượng là ai? - Người dùng thông thường (không phải admin, không phải khách vãng lai). Điều này quyết định quyền hạn và dữ liệu test.
Hành động cụ thể là gì? - Đăng nhập bằng email + mật khẩu. Không phải Google login, không phải số điện thoại. Chỉ email và mật khẩu.
Mục đích sau khi làm xong? - Vào trang quản lý đơn hàng. Sau khi đăng nhập thành công, phải redirect đúng chỗ, không phải trang khác.
Ba câu hỏi này giúp bạn không bỏ sót phạm vi cần test
Một user story hay đi kèm acceptance criteria (tiêu chí chấp nhận) - danh sách điều kiện để tính là "xong". Ví dụ:
- Đăng nhập đúng email + mật khẩu → chuyển sang trang đơn hàng
- Sai mật khẩu → hiển thị thông báo lỗi
- Email không tồn tại → hiển thị thông báo lỗi
- Sau 5 lần sai → khóa tài khoản 30 phút
Acceptance criteria chính là bản đồ test scenario của bạn. Mỗi dòng thường ứng với ít nhất một scenario. Tuyệt đối không bỏ qua phần này.
Xác định luồng chính và luồng phụ
Sau khi đọc xong user story và acceptance criteria, bước tiếp theo là phân chia luồng chính (happy path) và luồng phụ (alternative/negative path).
Luồng chính là kịch bản người dùng làm đúng hết, hệ thống phản hồi như kỳ vọng. Với ví dụ đăng nhập: nhập email đúng, mật khẩu đúng, bấm đăng nhập, chuyển sang trang đơn hàng. Đơn giản, suôn sẻ.
Luồng phụ là mọi trường hợp còn lại. Mình chia thành 2 nhóm để dễ nhớ:
Nhóm 1 - Alternative path: Người dùng làm khác nhưng vẫn hợp lệ. Ví dụ: quên mật khẩu rồi reset, đăng nhập bằng "Nhớ tôi" lần sau.
Nhóm 2 - Negative path: Người dùng nhập sai, hệ thống phải xử lý lỗi. Ví dụ: sai mật khẩu, email không tồn tại, để trống ô, nhập ký tự đặc biệt.
Luồng phụ thường chứa nhiều bug hơn luồng chính - đừng bỏ qua
Một mẹo mình hay dùng: sau khi xác định luồng chính, tự hỏi "điều gì có thể đi sai ở mỗi bước?". Bước nhập email: email sai format, email có khoảng trắng đầu/cuối, email quá dài. Bước nhập mật khẩu: sai, thiếu ký tự, copy-paste có space. Bước bấm nút: bấm nhiều lần liên tục, mạng chậm.
Mỗi câu trả lời là một test scenario tiềm năng.
Với người mới, tỉ lệ lý tưởng là khoảng 1 happy path : 3-4 negative/alternative paths. Nếu bạn viết nhiều happy path hơn negative, gần như chắc chắn đang bỏ sót bug.
Chuyển từ requirement sang test scenario: từng bước cụ thể
Test scenario không cần dài, không cần chi tiết như test case. Một test scenario tốt chỉ cần trả lời: "Sẽ test tình huống gì?" - một câu, rõ ràng, không mơ hồ.
Quy trình mình hay dùng:
Bước 1: Liệt kê tất cả acceptance criteria Chép hết ra, không bỏ dòng nào. Mỗi dòng là một điểm cần verify.
Bước 2: Với mỗi criteria, đặt câu hỏi "Và nếu...?"
- "Đăng nhập đúng thì chuyển trang đơn hàng" → Và nếu trang đơn hàng bị lỗi thì sao? Và nếu chưa có đơn hàng nào thì hiển thị gì?
- "Sai mật khẩu thì hiển thị lỗi" → Và nếu sai lần 1, lần 2, lần 5 thì thông báo có khác không?
Bước 3: Gom nhóm thành scenario Mỗi scenario = 1 tình huống rõ ràng, viết theo format: [Hành động] + [Dữ liệu/Điều kiện] + [Kết quả mong đợi]
Format đơn giản nhưng đủ để bất kỳ ai cũng reproduce được
Ví dụ thực tế cho chức năng đăng nhập:
| # | Test Scenario |
|---|---|
| 1 | Đăng nhập với email và mật khẩu đúng → chuyển trang đơn hàng |
| 2 | Đăng nhập với mật khẩu sai → hiển thị thông báo lỗi |
| 3 | Đăng nhập với email không tồn tại → hiển thị thông báo lỗi |
| 4 | Bỏ trống cả 2 trường → hiển thị validation |
| 5 | Bỏ trống email, nhập mật khẩu → validation email |
| 6 | Sai mật khẩu 5 lần liên tiếp → khóa tài khoản 30 phút |
| 7 | Đăng nhập email có khoảng trắng đầu/cuối → xử lý đúng |
| 8 | Đăng nhập sau khi tài khoản bị khóa → hiển thị thông báo khóa |
Nhìn bảng này, bạn thấy 7/8 scenario là negative/edge case. Đây là tỉ lệ bình thường. Chức năng đơn giản như đăng nhập đã ra 8 scenario - tính năng phức tạp hơn thường ra 15-20+.
Chưa cần biết sẽ test như thế nào - đó là việc của test case. Bước này chỉ cần biết test cái gì.
Checklist câu hỏi tự hỏi khi đọc requirement
Mình tổng hợp list câu hỏi này sau vài năm làm tester và hướng dẫn người mới. Mỗi lần nhận requirement mới, chạy qua hết list này trước khi viết bất kỳ test scenario nào.
Tải về để dùng ngay: Tải checklist câu hỏi đọc requirement
Về phạm vi và đối tượng:
- Tính năng này dành cho đối tượng người dùng nào? (admin, user thường, khách vãng lai?)
- Có điều kiện tiên quyết không? (phải đăng nhập trước? phải có dữ liệu gì trước?)
- Tính năng này ảnh hưởng đến module nào khác không?
Về dữ liệu đầu vào:
- Input có những loại nào? (text, số, file, ngày tháng?)
- Giá trị tối thiểu/tối đa là bao nhiêu?
- Những ký tự đặc biệt nào có thể xảy ra?
- Dữ liệu trống/null được xử lý thế nào?
Về luồng phụ:
- Điều gì xảy ra khi mạng chậm hoặc mất kết nối giữa chừng?
- Nếu người dùng làm đúng nhưng server lỗi thì sao?
- Có race condition không? (bấm nút 2 lần cùng lúc?)
Về kết quả và thông báo:
- Sau khi thành công, hệ thống làm gì? Redirect đâu? Thông báo gì?
- Thông báo lỗi có đủ rõ để user hiểu không?
- Dữ liệu có được lưu đúng vào database không?
In ra dán cạnh màn hình - mình từng làm vậy suốt 6 tháng đầu
Về giới hạn và bảo mật:
- Có rate limiting không? (gửi request quá nhiều lần?)
- Dữ liệu nhạy cảm có bị hiển thị không đúng chỗ không?
- Người dùng có thể bypass bước nào không?
Không cần trả lời hết ngay trong lần đọc đầu. Câu hỏi nào chưa có câu trả lời trong tài liệu → hỏi BA hoặc dev ngay, đừng giả định.
Ví dụ thực hành: đọc requirement tính năng đặt hàng
Mình lấy ví dụ gần với thực tế hơn để bạn tự luyện. Đây là requirement kiểu tài liệu ngắn, không phải user story chuẩn - vì thực tế nhiều công ty viết requirement theo kiểu này:
"Chức năng thêm sản phẩm vào giỏ hàng: Người dùng có thể bấm nút 'Thêm vào giỏ' trên trang chi tiết sản phẩm. Số lượng trong giỏ hàng phải cập nhật ngay lập tức. Nếu sản phẩm đã có trong giỏ, tăng số lượng thêm 1. Chỉ cho phép thêm tối đa 99 sản phẩm cùng loại."
Bây giờ áp dụng quy trình 3 bước:
Bước 1 - Liệt kê những gì tài liệu đề cập:
- Bấm nút "Thêm vào giỏ" từ trang chi tiết
- Số lượng giỏ cập nhật ngay lập tức
- Sản phẩm đã có trong giỏ → tăng thêm 1
- Tối đa 99 cùng loại
Bước 2 - Hỏi "Và nếu...?" cho từng điểm:
- Tối đa 99: Và nếu số lượng đang là 99 rồi bấm thêm thì sao? Có thông báo không?
- Cập nhật ngay lập tức: Và nếu mạng chậm thì icon giỏ có lag không?
- Tăng thêm 1: Và nếu bấm 2 lần nhanh cùng lúc thì tăng 1 hay 2?
- Trang chi tiết: Chỉ từ trang này hay còn từ trang danh sách cũng có nút này?
Từ 4 dòng requirement ra 12+ scenario - đây là lý do tester không thể đọc lướt
Bước 3 - Các scenario cần test:
- Thêm sản phẩm chưa có trong giỏ → số lượng giỏ tăng 1
- Thêm sản phẩm đã có trong giỏ → số lượng sản phẩm đó tăng 1
- Thêm sản phẩm khi số lượng đang là 99 → kiểm tra hành vi (block? thông báo?)
- Bấm nút 2 lần nhanh liên tiếp → không tăng 2 cùng lúc
- Thêm vào giỏ khi chưa đăng nhập → redirect login hay vẫn cho thêm?
- Thêm vào giỏ khi sản phẩm hết hàng → nút có disabled không?
- Kiểm tra số lượng hiển thị ở icon giỏ hàng có cập nhật đúng không
- Kiểm tra tổng tiền có tính lại sau khi thêm không
Bạn thấy không? Requirement 4 dòng ra được 8+ scenario. Và tất cả scenario 3-8 đều không được đề cập trực tiếp trong tài liệu. Tester giỏi là người biết nhìn thấy những gì không được viết ra.
Thấy khó ở bước "hỏi và nếu" là bình thường - đây là kỹ năng cần thời gian rèn luyện. Mình tự tin hơn sau khoảng 2-3 tháng thực hành đều đặn. Không cần rush.