Đọc requirement cho tester trái ngành: Cách hiểu user story và phát hiện điểm cần test
3 tháng trước · 9 phút đọc
Tại sao requirement lại khiến tester mới "đứng hình"?
Mình nhớ lần đầu được giao tài liệu requirement để viết test case. Cầm lên đọc, thấy toàn câu kiểu "As a user, I want to login so that I can access my dashboard". Và mình cứ ngồi hỏi: Thế thì test cái gì?
Đây là nỗi sợ phổ biến của hầu hết tester chuyển nghề. Không phải vì bạn kém, mà vì không ai dạy cách đọc tài liệu theo góc nhìn tester. Dev đọc requirement để hiểu cần code gì. BA đọc để confirm yêu cầu. Còn tester cần đọc để tìm ra tất cả những gì có thể sai.
Góc nhìn đó khác hoàn toàn.
Ba người đọc cùng một tài liệu, nhưng tìm ba thứ khác nhau
Bài này mình sẽ hướng dẫn từng bước: từ cấu trúc user story, cách tách luồng nghiệp vụ, đến việc biến requirement thành checklist test cụ thể. Không cần kinh nghiệm IT trước, chỉ cần đọc kỹ và làm theo.
User story là gì và tại sao bạn cần hiểu nó?
User story (câu chuyện người dùng) là cách phổ biến nhất để viết requirement trong các team phần mềm hiện đại. Cấu trúc chuẩn trông như này:
As a [loại người dùng], I want to [hành động], so that [lý do/lợi ích].
Ví dụ thực tế từ app thương mại điện tử:
As a customer, I want to filter products by price range, so that I can find items within my budget.
Dịch ra: Khách hàng muốn lọc sản phẩm theo khoảng giá, để tìm được hàng phù hợp túi tiền.
Cấu trúc user story - đọc được 3 phần này là hiểu được 70% requirement
Nhìn vào đây, tester cần rút ra 3 thứ ngay lập tức:
Ai dùng tính năng? (customer - khách hàng, không phải admin hay seller)
Họ làm gì? (filter - lọc theo khoảng giá)
Mục đích cuối là gì? (tìm được hàng đúng budget)
Tại sao cần biết mục đích? Vì đây là thứ giúp bạn đặt câu hỏi. Nếu tính năng filter chạy nhưng kết quả trả về sai sản phẩm, người dùng vẫn không đạt được mục đích. Bug đó quan trọng hơn nhiều so với một lỗi UI nhỏ.
Thực ra, bên dưới mỗi user story còn có acceptance criteria (tiêu chí chấp nhận) - đây mới là nơi tester "đào vàng". Mình sẽ nói kỹ ở phần sau.
Acceptance criteria - "mỏ vàng" của tester
Acceptance criteria (tiêu chí chấp nhận - gọi tắt là AC) là danh sách điều kiện cụ thể để tính năng được xem là hoàn thành. Đây là phần tester cần đọc kỹ nhất, vì AC chính là "đề thi" của mỗi tính năng.
Ví dụ AC cho tính năng filter sản phẩm theo giá:
1. Người dùng có thể nhập giá tối thiểu và tối đa
2. Hệ thống chỉ hiển thị sản phẩm trong khoảng giá đã chọn
3. Nếu không có sản phẩm, hiển thị thông báo "Không tìm thấy sản phẩm"
4. Giá tối thiểu không được lớn hơn giá tối đa
5. Cho phép nhập giá từ 0đ đến 999.999.999đ
Mỗi dòng AC = ít nhất 1 test case. Nhưng tester giỏi không dừng ở đó.
Từ 5 dòng AC, tester có thể khai thác ra 15-20 test case
Bạn đọc AC số 4: "Giá tối thiểu không được lớn hơn giá tối đa". Từ đây bạn sẽ test:
- Nhập min = 100.000đ, max = 500.000đ → kết quả đúng?
- Nhập min = 500.000đ, max = 100.000đ → hệ thống báo lỗi không?
- Nhập min = max = 200.000đ → xử lý thế nào?
- Bỏ trống một trong hai ô → hệ thống xử lý thế nào?
Từ 1 dòng AC, bạn có ngay 4 test case. Đây là cách tư duy tester - không đọc để hiểu, đọc để đặt câu hỏi.
Cách tách user story thành luồng nghiệp vụ
Luồng nghiệp vụ (business flow) là chuỗi bước người dùng thực hiện từ đầu đến cuối một tính năng. Tách được luồng này, bạn biết ngay cần test từng bước nào.
Mình lấy ví dụ tính năng đặt hàng trên app mua sắm. User story ban đầu chỉ có 1 câu, nhưng bên dưới là cả một luồng phức tạp:
Bước 1: Người dùng chọn sản phẩm → thêm vào giỏ hàng Bước 2: Vào giỏ hàng → kiểm tra lại Bước 3: Chọn địa chỉ giao hàng Bước 4: Chọn phương thức thanh toán Bước 5: Xác nhận đặt hàng → nhận thông báo
Luồng đặt hàng - mỗi mũi tên là một điểm có thể xảy ra lỗi
Mỗi bước là một điểm cần test. Và không chỉ test bước đó chạy được (happy path), mà còn test xem nếu xảy ra sự cố tại bước đó thì sao:
- Bước 1: Sản phẩm hết hàng → vẫn thêm được vào giỏ không?
- Bước 3: Địa chỉ nằm ngoài vùng giao → thông báo rõ không?
- Bước 4: Thẻ hết tiền → thông báo lỗi gì, có rollback đơn hàng không?
- Bước 5: Mất mạng ngay lúc xác nhận → đơn hàng tạo chưa?
Cách tách luồng đơn giản nhất: dùng giấy/whiteboard vẽ ra từng bước theo thứ tự thời gian. Sau đó hỏi: "Tại bước này, người dùng có thể làm gì sai? Hệ thống có thể lỗi gì?"
Không cần phần mềm fancy. Tờ giấy A4 và cây bút là đủ cho buổi phân tích đầu tiên.
3 loại luồng cần test trong mọi tính năng
Dù là tính năng gì, từ đăng nhập đến thanh toán, tester đều cần bao phủ 3 loại luồng. Bỏ sót loại nào, bug sẽ nổ ở loại đó.
Happy path là luồng chính - mọi thứ diễn ra đúng như kịch bản lý tưởng. Nhập đúng email, đúng mật khẩu, bấm login, vào được trang chủ. Đây là thứ ai cũng test trước tiên.
Negative case (trường hợp âm) là khi người dùng làm sai: nhập sai, bỏ trống, nhập dữ liệu không hợp lệ. Hệ thống cần xử lý và báo lỗi rõ ràng, không được crash hay im lặng. Đây là nơi hầu hết bug ẩn náu.
Edge case (trường hợp biên) là những tình huống cực đoan hoặc hiếm gặp nhưng hoàn toàn có thể xảy ra: mật khẩu dài 255 ký tự, tên người dùng toàn ký tự đặc biệt, đặt hàng 999 sản phẩm cùng lúc, mạng chập chờn giữa chừng.
Không bao phủ đủ 3 loại - chắc chắn bỏ sót bug
Mình từng bỏ qua edge case ở tính năng upload ảnh, chỉ test file ảnh thông thường. Đến khi user upload file .jpg được đổi tên từ file .exe, hệ thống chấp nhận thẳng. Bug đó nặng hơn nhiều so với một lỗi giao diện.
Checklist nhanh để nhớ:
- [ ] Happy path: luồng đúng, đầy đủ thông tin
- [ ] Negative: thiếu thông tin, sai format, sai điều kiện
- [ ] Edge: dữ liệu cực đoan, điều kiện biên, môi trường không ổn định
Câu hỏi cần hỏi BA/PO khi đọc requirement
BA (Business Analyst) và PO (Product Owner) là người hiểu requirement rõ nhất. Tester mới hay ngại hỏi vì sợ "hỏi ngớ ngẩn". Thực ra, hỏi đúng còn quan trọng hơn biết nhiều.
Mình tổng hợp lại bộ câu hỏi mình hay dùng khi nhận tài liệu mới:
Về dữ liệu đầu vào:
- Trường này có bắt buộc không? Nếu bỏ trống thì xử lý thế nào?
- Giới hạn ký tự tối thiểu/tối đa là bao nhiêu?
- Định dạng dữ liệu hợp lệ là gì? (email, số điện thoại, ngày tháng...)
- Ký tự đặc biệt có được phép không?
Về xử lý lỗi:
- Khi xảy ra lỗi, hệ thống hiển thị thông báo gì?
- Sau khi lỗi, dữ liệu người dùng đã nhập có giữ lại không?
- Có timeout không? Bao nhiêu giây?
Về quyền truy cập:
- Tính năng này ai được dùng? (user thường, admin, seller...)
- Người không có quyền truy cập thì thấy gì?
Hỏi đúng câu hỏi sớm - tiết kiệm hàng giờ test lại sau
Về trạng thái và luồng:
- Sau khi thực hiện xong, người dùng được chuyển đến đâu?
- Tính năng này có ảnh hưởng đến tính năng khác không?
- Có trạng thái trung gian nào không? (đang xử lý, chờ duyệt...)
Mình đặt tất cả câu hỏi này vào một file, gửi cho BA trước buổi họp. Tiết kiệm thời gian cho cả hai bên hơn là hỏi lẻ tẻ từng cái.
Tải ngay mẫu câu hỏi đầy đủ để dùng ngay: Tải mẫu câu hỏi cho BA/PO