Soát User Story trước khi viết test: checklist bắt lỗi yêu cầu từ sớm

Đối chiếu Story ↔ design ↔ nguồn dữ liệu, tìm chỗ mơ hồ theo 5 nhóm câu hỏi, và cách viết câu hỏi để BA trả lời nhanh mà không phải họp.

StoryPass5 phút đọc

Có một loại bug không nằm trong code: bug trong yêu cầu. AC viết “hiển thị giá trị mới nhất” nhưng không nói mới nhất theo ngày cập nhật hay theo kỳ dữ liệu. Design vẽ 3 tab còn Story chỉ nhắc 2. Dev đọc theo một kiểu, QA hiểu theo kiểu khác, và cả hai đều “đúng”.

Phát hiện những chỗ này trước khi viết test rẻ hơn rất nhiều so với phát hiện lúc đang test, khi Dev đã code xong và sprint sắp hết. Bài này là checklist mình dùng để soát Story, cộng với cách đặt câu hỏi để BA trả lời được ngay.

Đối chiếu ba nguồn, không chỉ đọc Story

Đọc kỹ AC là chưa đủ. Một Story thường có ít nhất ba nguồn thông tin, và lỗi hay nằm ở khoảng giữa chúng:

Nguồn Trả lời câu hỏi
Story / AC Hệ thống phải làm gì?
Design (Figma) Trông như thế nào, có những trạng thái nào?
Nguồn dữ liệu / API doc Dữ liệu thật có những gì, ở dạng nào?

Mỗi khi hai nguồn nói khác nhau, đó là một câu hỏi. Ví dụ: Figma vẽ số có 2 chữ số thập phân, nhưng nguồn dữ liệu chỉ có số nguyên — vậy hiển thị 12 hay 12.00?

Checklist 5 nhóm

1. Số liệu

  • Đơn vị là gì, hiển thị ở đâu (tiêu đề, trục, tooltip, từng ô)?
  • Làm tròn bao nhiêu chữ số? Làm tròn ở backend hay frontend?
  • Định dạng số: dấu phân cách hàng nghìn, hậu tố K/M/B, số âm hiển thị -12 hay (12)?
  • Định dạng ngày theo tần suất dữ liệu: ngày, tháng, quý, năm hiển thị khác nhau thế nào?
  • Giá trị đặc biệt: 0, rỗng, null, âm, cực lớn — hiển thị gì?
  • Kỳ dữ liệu: “mới nhất” là mới nhất theo cái gì? Múi giờ nào?

2. Trạng thái màn hình

  • Đang tải, không có dữ liệu, lỗi API, không có quyền, dữ liệu chỉ có một phần.
  • Design có vẽ đủ các trạng thái này chưa? Nếu không, mặc định là gì?

3. Hành vi

  • Khi vào trang, tab/bộ lọc/kỳ nào được chọn mặc định?
  • Nhiều bộ lọc kết hợp với nhau thế nào? Đổi tab có giữ bộ lọc không?
  • Sắp xếp mặc định theo cột nào, tăng hay giảm?
  • Export xuất ra những gì: đúng dữ liệu đang lọc hay toàn bộ? Tên file, định dạng?
  • Legend, tooltip có đổi theo khi đổi tab hoặc đơn vị tiền tệ không?

4. Ngoại lệ và giới hạn

  • Tên dài, danh sách rất nhiều mục, chuỗi có ký tự đặc biệt.
  • Màn hình nhỏ: cột nào ẩn, chart co thế nào?
  • Đa ngôn ngữ: chữ tiếng Anh dài hơn có làm vỡ layout không?

5. Mâu thuẫn giữa các nguồn

  • Story và design khác nhau ở đâu?
  • Design và dữ liệu thật có khớp không (số kỳ, số nhóm, tên nhóm)?
  • Story này có làm thay đổi hành vi của trang nào khác không?

Viết câu hỏi để BA trả lời nhanh

Một danh sách 15 câu hỏi dài dòng sẽ bị để đó đến cuối sprint. Vài nguyên tắc giúp câu hỏi được trả lời ngay:

Đánh số và phân mức. Chia làm ba mức:

  • Chặn: không trả lời thì không viết được test hoặc dễ code sai.
  • Cần rõ: có thể đoán, nhưng đoán sai sẽ tốn công sửa.
  • Gợi ý: góp ý cải thiện, không cần trả lời trước khi test.

Luôn kèm “QA tạm hiểu”. Thay vì hỏi mở, hãy đưa ra cách hiểu của bạn để BA chỉ cần xác nhận hoặc sửa:

#3 (Cần rõ) Tooltip hiển thị giá trị làm tròn mấy chữ số? QA tạm hiểu: 2 chữ số thập phân, giống bảng bên dưới.

So với câu hỏi “Tooltip làm tròn thế nào ạ?”, câu trên trả lời được trong 5 giây.

Trích dẫn nguồn. Ghi rõ AC nào, frame Figma nào, để người đọc không phải đi tìm.

Tag đúng người. Câu về nghiệp vụ tag BA, câu về API tag Dev backend, câu về giao diện tag Designer.

Không chờ BA mới viết test

Bạn không cần đợi mọi câu hỏi được trả lời. Viết test theo phần đã rõ, phần chưa rõ viết theo “QA tạm hiểu” và đánh dấu test đó đang chờ BA (một nhãn hoặc một dòng ghi chú). Khi BA trả lời:

  • Nếu trùng với cách bạn hiểu: bỏ đánh dấu, giữ nguyên test.
  • Nếu khác: sửa Expected của các test liên quan và chạy lại phần đã chạy.

Ghi lại quyết định

Mỗi câu BA đã chốt nên được lưu vào một chỗ cố định (một file decisions cho Story, hoặc comment tổng hợp trên Jira). Lợi ích:

  • Không báo lỗi lại những điểm đã chốt là “đúng thiết kế” ở vòng test sau.
  • Người mới vào dự án hiểu vì sao sản phẩm hoạt động như vậy.
  • Khi Story bị sửa AC, bạn biết ngay test nào bị ảnh hưởng.

Tóm tắt

  1. Đối chiếu Story ↔ design ↔ dữ liệu, không chỉ đọc AC.
  2. Soát theo 5 nhóm: số liệu, trạng thái, hành vi, ngoại lệ, mâu thuẫn.
  3. Câu hỏi đánh số, phân mức, kèm “QA tạm hiểu”, trích nguồn, tag đúng người.
  4. Viết test song song, đánh dấu test chờ BA.
  5. Lưu lại mọi quyết định đã chốt.

Làm đều đặn vài sprint, bạn sẽ thấy số bug “hiểu khác nhau” giảm hẳn — và BA bắt đầu gửi Story cho bạn đọc trước khi đưa vào sprint.

  • #user story
  • #review yêu cầu
  • #shift-left

StoryPass · Kiến thức QA thực chiến

Viết bởi một QA đang đi làm, để tự giải phóng mình khỏi những việc manual lặp lại mỗi sprint, rồi đóng gói lại thành qa-kit cho các bạn QA khác.