Đọc requirement và viết test scenario: Kỹ năng cốt lõi cho tester trái ngành
2 tháng trước · 11 phút đọc
Tại sao đọc requirement là kỹ năng số một của tester?
Mình nhớ lần đầu nhận dự án, BA (Business Analyst) đưa cho một file tài liệu mấy chục trang gọi là "requirement". Mình lướt qua, thấy toàn chữ, không biết bắt đầu từ đâu. Viết test case xong, dev review và hỏi: "Bạn test cái này dựa trên đâu?" Mình... không trả lời được.
Đó là lúc mình hiểu: tester không phải chỉ "bấm nút xem có lỗi không". Công việc thực sự bắt đầu từ trước khi có bất kỳ dòng code nào - từ lúc đọc requirement (yêu cầu phần mềm).
Requirement là bản đồ, test scenario là lộ trình - thiếu bản đồ thì đi đâu cũng lạc
Requirement là tài liệu mô tả phần mềm cần làm gì, dành cho ai, trong hoàn cảnh nào. Tester đọc requirement không phải để hiểu dev làm thế nào - mà để biết người dùng kỳ vọng gì, từ đó kiểm tra xem phần mềm có đáp ứng đúng hay không.
Nếu bỏ qua bước này, bạn sẽ test "theo cảm tính", dễ bỏ sót các trường hợp quan trọng và không chứng minh được mình test cái gì khi ai đó hỏi.
Requirement, user story, acceptance criteria - ba khái niệm hay bị nhầm
Ba thuật ngữ này liên quan nhau nhưng khác nhau hoàn toàn. Mình thấy nhiều bạn mới hay dùng lẫn lộn, dẫn đến đọc tài liệu mà không hiểu mình đang đọc cái gì.
Requirement (yêu cầu) là mức tổng quan nhất. Ví dụ: "Hệ thống cho phép người dùng đăng nhập". Đây là câu tuyên bố tính năng cần có.
User story (câu chuyện người dùng) là cách viết requirement theo góc nhìn người dùng, thường theo format:
As a [vai trò], I want to [hành động], So that [lợi ích]
Ví dụ: "As a registered user, I want to log in using my email or phone number, So that I can access my account securely."
User story trả lời ba câu hỏi: Ai cần? Cần làm gì? Để được gì? Hiểu ba câu hỏi này giúp bạn biết context của tính năng, từ đó không test "lạc đề".
Format user story chuẩn giúp tester xác định đúng đối tượng và mục đích trước khi viết test
Acceptance criteria (tiêu chí chấp nhận) là danh sách điều kiện cụ thể để coi tính năng "đạt". Đây là phần tester cần đọc kỹ nhất vì nó quy định rõ: "Test cái này pass khi nào, fail khi nào."
Ví dụ acceptance criteria cho tính năng đăng nhập:
- Đăng nhập thành công bằng email hợp lệ + đúng mật khẩu → chuyển vào trang chủ
- Đăng nhập thành công bằng số điện thoại hợp lệ + đúng mật khẩu → chuyển vào trang chủ
- Nhập sai mật khẩu 3 lần → tài khoản bị khóa tạm thời
- Email chưa đăng ký → hiển thị thông báo lỗi rõ ràng
Acceptance criteria chính là "luật" để bạn đánh giá phần mềm đúng hay sai. Không có nó, bạn không có cơ sở để kết luận bug hay không phải bug.
Cách phân tích user story để tìm ra cần test gì
Đọc user story xong, bước tiếp theo là "bóc tách" nó thành các trường hợp cần kiểm tra. Đây là kỹ năng quan trọng nhất - và cũng là thứ phân biệt tester tốt với tester trung bình.
Mình dùng ba câu hỏi để bóc tách:
1. Happy path là gì? - Trường hợp người dùng làm đúng mọi thứ, hệ thống hoạt động bình thường. Đây luôn là nơi bắt đầu.
2. Error case là gì? - Người dùng nhập sai, thiếu, hoặc nhập dữ liệu không hợp lệ. Hệ thống xử lý ra sao?
3. Edge case là gì? - Những trường hợp "biên giới" hiếm xảy ra nhưng có thể xảy ra. Ví dụ: email dài 254 ký tự (giới hạn tối đa theo chuẩn), mật khẩu chứa ký tự đặc biệt như &, <, >.
Ba loại test case: happy path, error case, edge case - bỏ sót loại nào cũng rủi ro
Áp dụng vào user story đăng nhập:
| Loại | Ví dụ |
|---|---|
| Happy path | Đăng nhập bằng email + mật khẩu đúng |
| Happy path | Đăng nhập bằng số điện thoại + mật khẩu đúng |
| Error case | Email đúng nhưng mật khẩu sai |
| Error case | Email không tồn tại trong hệ thống |
| Error case | Bỏ trống trường email |
| Edge case | Email có ký tự đặc biệt ([email protected]) |
| Edge case | Số điện thoại có dấu cộng ở đầu (+84...) |
| Edge case | Nhập đúng sau khi đã sai 2 lần |
Bạn thấy không - chỉ từ một user story ngắn, mình đã tìm được ít nhất 8 trường hợp cần kiểm tra. Tester không bịa ra các trường hợp này - mình suy luận từ requirement. Đó là lý do đọc requirement kỹ quan trọng hơn biết code.
Viết test scenario đúng cách - không dài, không thiếu
Test scenario (kịch bản kiểm thử) khác test case (trường hợp kiểm thử chi tiết) ở chỗ: scenario mô tả cái gì cần kiểm tra, còn test case mô tả từng bước kiểm tra như thế nào.
Nhiều bạn mới hay bỏ qua bước viết scenario, nhảy thẳng vào viết test case. Kết quả là test case bị rời rạc, không có cấu trúc, và dễ bỏ sót nhóm trường hợp quan trọng.
Một test scenario tốt cần trả lời được:
- Ai đang làm gì?
- Với dữ liệu gì?
- Kết quả mong đợi là gì?
Cấu trúc một test scenario: rõ đối tượng, rõ điều kiện, rõ kết quả
Ví dụ cụ thể cho tính năng đăng nhập bằng email:
Scenario 1: Đăng nhập thành công bằng email
- Người dùng đã đăng ký tài khoản trước đó
- Nhập đúng email và mật khẩu
- Kết quả mong đợi: Chuyển hướng vào trang chủ, hiển thị tên người dùng
Scenario 2: Đăng nhập thất bại - sai mật khẩu
- Người dùng đã đăng ký tài khoản
- Nhập đúng email, sai mật khẩu
- Kết quả mong đợi: Hiển thị thông báo "Mật khẩu không đúng", không chuyển trang
Scenario 3: Đăng nhập bằng email chưa đăng ký
- Nhập email không tồn tại trong hệ thống
- Kết quả mong đợi: Hiển thị thông báo lỗi phù hợp, không lộ thông tin tài khoản tồn tại
Scenario 4: Đăng nhập bằng số điện thoại hợp lệ
- Nhập số điện thoại đã đăng ký + đúng mật khẩu
- Kết quả mong đợi: Chuyển hướng vào trang chủ
Scenario 5: Tài khoản bị khóa sau 3 lần sai mật khẩu
- Nhập sai mật khẩu 3 lần liên tiếp
- Kết quả mong đợi: Tài khoản bị khóa, hiển thị thông báo và hướng dẫn mở khóa
Thấy chưa - mỗi scenario ngắn gọn, rõ điều kiện, rõ kết quả. Không cần dài dòng, không cần mô tả từng click từng bước - đó là việc của test case sau này.
Mình hay so sánh test scenario như mục lục của cuốn sách, còn test case là nội dung từng chương. Mục lục rõ thì nội dung mới có hướng.
Checklist: Bạn đã đọc đúng requirement chưa?
Trước khi bắt tay viết test scenario, mình hay tự kiểm tra lại bằng checklist này. Mình làm quen rồi thì chạy nhanh trong đầu được, nhưng hồi mới thì cần in ra đặt bên cạnh.
In checklist này ra, đặt cạnh máy tính - mình dùng suốt năm đầu đi làm
Về requirement:
- [ ] Mình đã hiểu tính năng này phục vụ ai chưa?
- [ ] Mình đã biết người dùng muốn làm gì chưa?
- [ ] Mình đã biết tính năng này mang lại lợi ích gì cho họ chưa?
- [ ] Mình đã đọc hết acceptance criteria chưa?
- [ ] Có điều kiện nào trong acceptance criteria mình chưa hiểu rõ không? (Nếu có, hỏi BA ngay)
Về test scenario:
- [ ] Đã có ít nhất 1 happy path scenario chưa?
- [ ] Đã có ít nhất 2-3 error case scenario chưa?
- [ ] Đã nghĩ đến edge case chưa? (ký tự đặc biệt, độ dài tối đa/tối thiểu, giá trị biên)
- [ ] Mỗi scenario đã có kết quả mong đợi cụ thể chưa?
- [ ] Scenario có trùng nhau không? (Nếu trùng thì gộp lại)
Câu hỏi cuối trước khi submit:
- [ ] Nếu mình là người dùng, mình có thể làm gì ngoài những gì mình đã viết scenario không?
Câu hỏi cuối này quan trọng. Tester giỏi không chỉ nghĩ theo acceptance criteria - họ còn nghĩ theo cách người dùng thật sự sử dụng, kể cả những cách "không ngờ đến".
Tải checklist đầy đủ để dùng ngay: Tải checklist kiểm tra requirement
Thấy khó ở bước tìm edge case lúc đầu là bình thường. Mình cũng mất mấy sprint đầu mới bắt đầu nghĩ được ra các trường hợp ít phổ biến. Cách nhanh nhất là sau mỗi lần review requirement: hỏi thêm một câu - "Còn trường hợp nào khác không?" Hỏi chính mình, hỏi BA, hỏi dev.
Lỗi phổ biến khi mới đọc requirement - và cách tránh
Mình đã quan sát nhiều bạn trái ngành học testing, và có một số lỗi lặp đi lặp lại. Không phải vì các bạn không cẩn thận - mà vì chưa có thói quen.
Lỗi 1: Chỉ test happy path
Đây là lỗi phổ biến nhất. Test đăng nhập? Chỉ nghĩ đến: nhập đúng → vào được. Bỏ qua hết error case và edge case. Kết quả: bug nổ production ở những chỗ "tưởng không ai dùng".
Mình từng bỏ qua trường hợp người dùng nhập email có khoảng trắng ở cuối (ví dụ: [email protected] thay vì [email protected]). Hệ thống không trim khoảng trắng, đăng nhập thất bại mà người dùng không hiểu tại sao. Bug nhỏ, nhưng tệ với trải nghiệm.
Lỗi 2: Không đọc acceptance criteria, tự đoán
Requirement nói "đăng nhập bằng email hoặc số điện thoại". Bạn tự đoán số điện thoại format là 10 số. Thực ra acceptance criteria quy định: chấp nhận cả +84 ở đầu. Test theo đoán = test sai spec.
Lỗi 3: Không hỏi khi chưa rõ
Thấy acceptance criteria mơ hồ - ví dụ "hiển thị thông báo lỗi phù hợp" - nhưng không hỏi nội dung thông báo là gì. Kết quả: dev hiển thị thông báo tiếng Anh, bạn pass vì "có thông báo", nhưng BA kỳ vọng tiếng Việt. Bug từ misunderstanding.
Ba lỗi phổ biến khi đọc requirement - nhận ra sớm để tránh lặp lại
Cách tránh ba lỗi này đơn giản hơn bạn nghĩ:
- Sau khi đọc xong, ghi danh sách câu hỏi cho BA - đừng ngại hỏi
- Dùng checklist từ phần trước
- Với mỗi acceptance criteria mơ hồ, diễn giải lại bằng lời của mình và confirm với BA
BA không cắn bạn đâu. Hỏi sớm tốn 5 phút. Không hỏi, test sai, fix bug tốn 2 ngày.