Đọc User Story & Requirement Trong Agile: Hướng Dẫn Tester Fresher
6 tháng trước · 11 phút đọc
User story là gì và tại sao tester cần đọc kỹ?
Mình nhớ lần đầu vào dự án, team lead ném cho một file Jira với hàng chục user story. Nhìn vào, thấy toàn câu kiểu "Là người dùng, tôi muốn..." - không hiểu đây là spec hay gì. Mình đọc qua rồi bắt đầu viết test case ngay. Kết quả? Test case thiếu sạch, dev review xong hỏi "bạn test flow này ở đâu vậy?".
User story là cách team Agile mô tả một tính năng từ góc nhìn người dùng, không phải từ góc nhìn kỹ thuật. Format chuẩn trông như thế này:
As a [loại người dùng],
I want to [hành động muốn thực hiện],
So that [lợi ích nhận được].
Ví dụ thực tế từ một app đặt đồ ăn:
As a khách hàng,
I want to lọc nhà hàng theo khoảng cách,
So that tôi đặt được đồ ăn giao nhanh hơn.
User story viết từ góc nhìn người dùng, không phải kỹ thuật
Tại sao tester phải đọc kỹ? Vì user story chứa đủ thông tin để suy ra ai dùng, dùng làm gì, và kết quả kỳ vọng là gì. Ba yếu tố đó chính là xương sống của mọi test scenario. Bỏ qua một cái là miss case ngay.
Acceptance Criteria - phần quan trọng nhất mà fresher hay bỏ qua
User story một mình không đủ để test. Phần quyết định chất lượng test case chính là Acceptance Criteria (AC) - tiêu chí chấp nhận.
AC trả lời câu hỏi: "Tính năng này hoạt động đúng khi nào?". Nó là thoả thuận giữa BA (Business Analyst), dev và tester về định nghĩa "done".
Format AC phổ biến nhất trong dự án Việt là Given-When-Then:
Given [điều kiện ban đầu],
When [hành động người dùng thực hiện],
Then [kết quả mong đợi].
Áp vào ví dụ lọc nhà hàng ở trên:
Given người dùng đã bật GPS và đang ở màn hình tìm kiếm,
When chọn "Gần tôi" và kéo slider khoảng cách về 2km,
Then danh sách chỉ hiển thị nhà hàng trong vòng 2km, sắp xếp từ gần đến xa.
Mỗi AC là một test scenario tiềm năng - đừng bỏ qua dòng nào
Mỗi AC thường map 1-1 với ít nhất một test scenario. Thực tế, một AC có thể cần 3-5 test case để cover đủ (happy path + negative + edge case).
Lưu ý: Trong nhiều dự án Việt, AC không được viết theo Given-When-Then mà viết dạng bullet list. Ví dụ:
- Slider khoảng cách từ 1km đến 10km
- Không tìm thấy nhà hàng thì hiển thị "Không có kết quả"
- Nếu GPS tắt thì hiển thị thông báo yêu cầu bật
Dạng bullet list này vẫn dùng được, chỉ cần bạn biết chuyển sang test case.
Cách phân tích requirement trong môi trường Agile/Scrum
Trong Scrum, requirement không đến một lúc toàn bộ như waterfall. Nó đến từng sprint, từng backlog item, đôi khi thay đổi giữa chừng. Tester fresher hay bị choáng vì điều này.
Thực tế thì quy trình khá rõ:
Sprint Planning → team chọn user story vào sprint, tester ngồi nghe để hiểu scope
Refinement/Grooming → BA và dev làm rõ AC, tester hỏi thêm về edge case
Development → dev code, tester viết test case song song
Testing → tester verify theo AC đã thống nhất
Tester tham gia từ Planning, không đợi dev xong mới bắt đầu
Mình thấy fresher hay mắc một lỗi: đợi dev xong mới đọc requirement. Sai hoàn toàn. Bạn phải đọc user story ngay khi sprint bắt đầu, hỏi câu hỏi sớm, viết test case trước khi dev hoàn thành. Như vậy khi build sẵn sàng, bạn test ngay được.
Câu hỏi nên hỏi trong Refinement:
- "Trường hợp user chưa đăng nhập thì sao?"
- "Nếu API lỗi thì UI hiển thị gì?"
- "Dữ liệu cũ có bị ảnh hưởng không?"
- "Mobile và web behavior có khác nhau không?"
Không cần ngại hỏi. Hỏi sớm giúp tránh bug phát hiện trễ - chi phí fix bug cuối sprint gấp nhiều lần so với fix lúc đầu.
Template test scenario từ user story - áp thẳng vào dự án Việt
Bài toán thực tế: dự án app quản lý đơn hàng của một công ty logistics Việt Nam. User story:
As a nhân viên kho,
I want to cập nhật trạng thái đơn hàng (Đang xử lý / Đã giao / Hoàn trả),
So that khách hàng theo dõi được đơn hàng real-time.
AC:
- Chỉ nhân viên có role "Kho" mới cập nhật được
- Trạng thái chỉ được đi theo chiều: Đang xử lý → Đã giao hoặc Đang xử lý → Hoàn trả
- Sau khi cập nhật, khách hàng nhận SMS thông báo trong vòng 2 phút
- Log lịch sử thay đổi phải được lưu
Template test scenario chuẩn áp dụng ngay cho dự án thực
Áp dụng template:
Test Scenario 1 - Happy path:
Scenario: Nhân viên kho cập nhật đơn hàng thành "Đã giao" thành công
Given: User đăng nhập với role "Kho", đơn hàng đang ở trạng thái "Đang xử lý"
When: Chọn đơn → nhấn "Cập nhật" → chọn "Đã giao" → xác nhận
Then: Trạng thái đổi thành "Đã giao", khách nhận SMS trong 2 phút, log được lưu
Test Scenario 2 - Negative (sai role):
Scenario: Nhân viên văn phòng KHÔNG cập nhật được trạng thái
Given: User đăng nhập với role "Văn phòng"
When: Mở trang chi tiết đơn hàng
Then: Nút "Cập nhật trạng thái" bị ẩn hoặc disabled
Test Scenario 3 - Edge case (đi ngược flow):
Scenario: Không thể đổi từ "Đã giao" về "Đang xử lý"
Given: Đơn hàng đang ở trạng thái "Đã giao"
When: Cố ý chọn "Đang xử lý" qua dropdown (nếu có)
Then: Hệ thống không cho phép, hiển thị thông báo lỗi
Tải template test scenario đầy đủ (có sẵn format cho 5 loại tính năng phổ biến): Tải template test scenario (Markdown)
Checklist 7 bước đọc user story không miss case
Sau 4 năm làm tester và cũng từng đào tạo nhiều bạn trái ngành, mình đúc ra 7 bước này. Không cần nhớ hết lý thuyết - cứ theo 7 bước là bắt được 90% case quan trọng.
7 bước này giúp mình không bao giờ miss case lớn trong sprint
Bước 1 - Xác định Actor AI đang dùng tính năng này? Một app có thể có nhiều role: admin, user thường, guest. Mỗi role cần test riêng.
Bước 2 - Xác định Action chính Hành động chính người dùng thực hiện là gì? Đây là happy path - luôn test cái này đầu tiên.
Bước 3 - Liệt kê điều kiện tiên quyết Cần gì trước khi thực hiện action? Đã đăng nhập chưa? Có dữ liệu sẵn chưa? Thiếu điều kiện tiên quyết là bug phổ biến.
Bước 4 - Hỏi "Nếu không?" Với mỗi AC, hỏi: "Nếu điều kiện này không đúng thì sao?" - đây là nguồn negative test case.
Bước 5 - Tìm giới hạn dữ liệu Số lượng tối đa, ký tự đặc biệt, trường bắt buộc/tùy chọn. Ví dụ: tên sản phẩm tối đa bao nhiêu ký tự?
Bước 6 - Kiểm tra integration Tính năng này liên quan gì đến tính năng khác? Thay đổi ở đây có ảnh hưởng màn hình khác không?
Bước 7 - Xác nhận kết quả kỳ vọng Mỗi test case phải có expected result cụ thể. Không phải "hiển thị thông báo" mà phải là "hiển thị thông báo 'Cập nhật thành công' màu xanh lá, tắt sau 3 giây".
Tải checklist này dạng file để dùng trong sprint: Tải checklist 7 bước (Interactive HTML)
Câu hỏi hay gặp khi mới làm - và câu trả lời thực tế
"User story viết mơ hồ, không biết test gì?"
Hỏi BA hoặc PO ngay. Đừng tự đoán rồi test sai hướng. Câu hỏi mẫu: "Story này AC chưa có, mình có thể hỏi thêm không?" - không ai từ chối câu hỏi này cả.
"Requirement thay đổi giữa sprint, test case cũ có dùng được không?"
Phải update. Test case cũ dựa trên AC cũ - nếu AC thay đổi, test case phải theo. Đây là lý do tester giỏi luôn link test case với user story cụ thể, không viết "lơ lửng".
"Không biết code, có đọc hiểu requirement kỹ thuật không?"
Hoàn toàn được. Phần lớn test case manual không cần biết code. Requirement kỹ thuật (API spec, DB schema) là tham khảo thêm, không bắt buộc với manual tester giai đoạn đầu.
Không biết code vẫn viết test case tốt - chỉ cần logic và tỉ mỉ
"Dự án không dùng Scrum, user story có áp dụng được không?"
User story và AC là kỹ năng phân tích - dùng được ở bất kỳ methodology nào. Dù waterfall hay Kanban, bạn vẫn cần hiểu "ai cần gì và kết quả ra sao" trước khi test.
Thấy bỡ ngỡ ở phần này là bình thường. Mình cũng mất cả tháng đầu mới quen với cách đọc requirement kiểu Agile. Đọc qua một lần chưa đủ - cần luyện tay bằng cách thử phân tích user story thật.
Nếu muốn thực hành có hướng dẫn, khóa Kiểm thử phần mềm có phần bài tập phân tích requirement từ dự án mẫu - khá sát với môi trường làm việc thực tế.
Bắt đầu từ đâu khi bạn là fresher trái ngành?
Không cần đọc hết tài liệu Agile mới bắt tay vào. Bắt đầu ngay với 3 việc này:
Việc 1: Lấy một user story thật (của team, hoặc tự tìm trên mạng) và thử viết 3 test scenario theo template Given-When-Then. Không cần đúng 100% - cần thực hành.
Việc 2: Áp checklist 7 bước vào user story đó. Xem bước nào bạn hay bỏ qua nhất.
Việc 3: Hỏi một người trong team (BA, dev, senior tester) review test scenario của bạn. Feedback trực tiếp từ người có kinh nghiệm nhanh hơn đọc sách gấp nhiều lần.
Thực hành với user story thật > đọc lý thuyết một mình
Một điều mình muốn nhấn mạnh: tester không cần biết code, nhưng phải biết logic. Kỹ năng phân tích requirement, đặt câu hỏi đúng, và tư duy "what can go wrong" - đây là thứ làm tester giỏi hơn là biết viết script.
Nhiều bạn trái ngành trong lớp mình - từ kế toán, kiến trúc, sư phạm - sau 2-3 tháng luyện đọc user story là viết test case không kém fresher IT. Lý do đơn giản: logic tốt, cẩn thận, không vội.
25, 28, 32 tuổi chuyển ngành vẫn được. Quan trọng là bắt đầu và thực hành đủ.
Bài tiếp mình sẽ đi vào viết bug report chuẩn từ những case tìm được qua quá trình test user story. Bookmark lại nhé - phần đó quan trọng không kém.