Đọc Requirement và viết Test Scenario: Kỹ năng cốt lõi cho tester trái ngành không code
2 tháng trước · 9 phút đọc
Đọc requirement mà không hiểu - mình từng ở đó
Lần đầu được giao một tài liệu requirement dày mấy trang, mình đọc xong mà không biết bắt đầu test từ đâu. Toàn chữ là chữ, vài chỗ còn viết kiểu "hệ thống shall validate input theo business rule". Business rule nào? Validate thế nào? Không ai giải thích thêm.
Đó là cảm giác rất phổ biến với người mới - đặc biệt nếu bạn từ ngành khác chuyển sang. Tin tốt là: đọc requirement không cần biết code. Chỉ cần biết đặt đúng câu hỏi.
Requirement rõ ràng là nền tảng để viết test scenario không bỏ sót
Bài này mình sẽ hướng dẫn từng bước: đọc requirement như thế nào, rút ra điểm cần test ra sao, và viết test scenario đủ rõ để người khác cũng hiểu bạn định test gì.
Requirement là gì và có mấy dạng?
Requirement (tạm dịch: tài liệu yêu cầu) là văn bản mô tả một tính năng hoặc hệ thống cần làm gì. Đây là "đầu vào" chính để bạn biết cần test những gì.
Trong thực tế, bạn sẽ gặp 2-3 dạng phổ biến:
User Story - dạng ngắn gọn, viết từ góc độ người dùng:
"As a user, I want to log in with email and password, so that I can access my account."
Dịch ra: "Với tư cách người dùng, mình muốn đăng nhập bằng email và mật khẩu để vào tài khoản."
Specification (tài liệu đặc tả) - dạng chi tiết hơn, liệt kê từng điều kiện:
"Hệ thống phải hiển thị thông báo lỗi khi email không đúng định dạng. Thông báo lỗi phải xuất hiện trong vòng 2 giây."
Acceptance Criteria (tiêu chí chấp nhận) - thường đi kèm User Story, liệt kê điều kiện để coi là "done":
- Đăng nhập thành công với email và mật khẩu đúng
- Hiển thị lỗi khi sai mật khẩu
- Khóa tài khoản sau 5 lần sai liên tiếp
Ba dạng requirement phổ biến - mỗi dạng có mức chi tiết khác nhau
Bạn không cần nhớ hết định nghĩa hàn lâm. Điều quan trọng là khi đọc bất kỳ dạng nào, bạn phải trả lời được: "Người dùng muốn làm gì, hệ thống phản hồi ra sao?"
Cách phân tích requirement để tìm điểm cần test
Đọc requirement không phải là đọc một lượt rồi thôi. Mình thường đọc 2-3 lần với mục tiêu khác nhau.
Lần 1: Hiểu flow chính. Tính năng này làm gì? Người dùng bắt đầu từ đâu, kết thúc ở đâu?
Lần 2: Tìm điều kiện và ràng buộc. Requirement có nói "phải", "không được", "chỉ khi", "nếu... thì..." ở đâu không? Đó là nơi nhiều bug ẩn nấp nhất.
Lần 3: Tìm chỗ thiếu. Requirement nói người dùng nhập email - nhưng nếu email bỏ trống thì sao? Nếu email quá dài thì sao? Những chỗ không nói rõ chính là chỗ bạn cần hỏi hoặc tự suy ra.
Ba lần đọc requirement với mục tiêu khác nhau - mỗi lần tìm một lớp thông tin
Mình lấy ví dụ với tính năng đăng nhập:
User Story: "As a user, I want to log in with email and password." Acceptance Criteria:
- Đăng nhập thành công → vào trang dashboard
- Sai mật khẩu → hiển thị thông báo lỗi
- Sau 5 lần sai → khóa tài khoản
Sau khi đọc kỹ, mình liệt kê câu hỏi:
- Email đúng định dạng hay sai định dạng (thiếu @) thì sao?
- Mật khẩu có phân biệt hoa thường không?
- Khóa tài khoản bao lâu? Có tự mở khóa không?
- Nếu để trống email hoặc password và bấm đăng nhập thì sao?
Những câu hỏi này sẽ trở thành test scenario của bạn. Requirement đã trả lời câu nào thì bạn test theo, chưa trả lời thì hỏi BA/PM hoặc dev trước khi test.
Test Scenario và Test Case - khác nhau chỗ nào?
Nhiều bạn mới học hay dùng lẫn lộn hai khái niệm này. Mình giải thích thật đơn giản:
Test Scenario = kịch bản tổng quát - mô tả điều gì cần được kiểm tra.
Test Case = bước thực hiện chi tiết - mô tả làm gì cụ thể để kiểm tra điều đó.
Ví dụ với tính năng đăng nhập:
| Ví dụ | |
|---|---|
| Test Scenario | Đăng nhập với email đúng, mật khẩu đúng |
| Test Case | 1. Mở trình duyệt, vào trang login. 2. Nhập email: [email protected]. 3. Nhập password: Test@123. 4. Click nút Đăng nhập. 5. Kiểm tra: chuyển sang trang dashboard. |
Khi mới bắt đầu, bạn thường viết Test Scenario trước để bao phủ hết các tình huống, sau đó chi tiết hóa thành Test Case cho từng cái.
Test Scenario là bản phác thảo, Test Case là bản vẽ kỹ thuật chi tiết
Thấy khó phân biệt ở bước này là bình thường. Mình cũng mất cả tuần đầu mới quen. Điểm mấu chốt để nhớ: Scenario trả lời "cần test cái gì", Case trả lời "test như thế nào".
Cách viết Test Scenario rõ ràng - template thực tế
Scenario viết rõ thì ai đọc cũng hiểu bạn định test gì. Mình thường dùng cấu trúc sau:
[Hành động] + [Điều kiện] + [Kết quả mong đợi]
Ví dụ cụ thể:
- Đăng nhập với email đúng, mật khẩu đúng → vào được trang dashboard
- Đăng nhập với mật khẩu sai → hiển thị thông báo "Sai mật khẩu"
- Đăng nhập với email để trống → hiển thị thông báo yêu cầu nhập email
- Đăng nhập với email không đúng định dạng (thiếu @) → hiển thị thông báo lỗi định dạng
- Đăng nhập sai mật khẩu 5 lần liên tiếp → tài khoản bị khóa
Bây giờ áp dụng cho tính năng search (tìm kiếm sản phẩm trên Shopee):
- Tìm kiếm từ khóa tồn tại ("điện thoại") → hiển thị danh sách kết quả liên quan
- Tìm kiếm từ khóa không tồn tại ("asdfjkl") → hiển thị thông báo "Không tìm thấy kết quả"
- Tìm kiếm với ô tìm kiếm trống → không thực hiện search hoặc thông báo nhập từ khóa
- Tìm kiếm từ khóa có ký tự đặc biệt (<script>, @#$) → hệ thống xử lý an toàn, không bị lỗi
Template: Hành động + Điều kiện + Kết quả mong đợi - áp dụng được cho mọi tính năng
Và với tính năng filter (lọc sản phẩm theo giá):
- Lọc sản phẩm trong khoảng giá 100k - 500k → chỉ hiển thị sản phẩm trong khoảng đó
- Lọc sản phẩm với giá tối thiểu > giá tối đa → thông báo lỗi hoặc không cho lọc
- Lọc sản phẩm với giá = 0 → hệ thống xử lý hợp lý, không bị lỗi
- Lọc sản phẩm kết hợp nhiều điều kiện (giá + danh mục + đánh giá) → kết quả đúng với tất cả điều kiện
Tải template scenario bên dưới để bắt đầu thực hành ngay: Tải template Test Scenario
Cách tìm edge case - bước nhiều tester mới hay bỏ qua
Edge case (trường hợp biên) là những tình huống ít xảy ra trong thực tế nhưng lại hay gây bug. Mình từng bỏ qua vì nghĩ "ai mà nhập kiểu đó". Rồi production bị lỗi đúng vì cái "ai mà nhập" đó.
Cách tìm edge case không cần code. Chỉ cần đặt câu hỏi theo 4 hướng:
1. Giới hạn số lượng/kích thước
- Tối thiểu bao nhiêu ký tự? Tối đa bao nhiêu?
- Nếu nhập vượt giới hạn thì sao?
- Ví dụ: password yêu cầu 8-20 ký tự. Bạn cần test với 7 ký tự (dưới min), 8 ký tự (đúng min), 20 ký tự (đúng max), 21 ký tự (vượt max).
2. Dữ liệu đặc biệt
- Ký tự đặc biệt: @, #, $, %, <, >, dấu nháy đơn/kép
- Emoji, tiếng Việt có dấu, tiếng Trung/Nhật
- Khoảng trắng đầu/cuối chuỗi (space ẩn)
- Ví dụ: tên sản phẩm có dấu ", nếu hệ thống không xử lý đúng có thể bị lỗi SQL hoặc hiển thị sai.
3. Trạng thái đặc biệt
- Người dùng chưa đăng nhập cố vào trang cần đăng nhập
- Tài khoản bị khóa/chưa kích hoạt
- Session hết hạn giữa chừng
4. Kết hợp điều kiện
- Nhiều filter cùng lúc
- Thực hiện action liên tiếp nhanh (double click)
- Dùng Back của trình duyệt sau khi submit form
Bốn hướng tìm edge case - áp dụng cho hầu hết mọi tính năng
Không cần tìm hết edge case trước khi bắt đầu test. Tìm được cái nào, thêm vào scenario cái đó. Làm quen dần, não sẽ tự động nhảy vào mode "à vậy nếu... thì sao?"