Đọc Hiểu Requirement: Kỹ Năng Tester Trái Ngành Phải Thành Thạo
6 tháng trước · 11 phút đọc
Tại sao đọc requirement là kỹ năng số 1 của tester?
Mình nhớ lần đầu nhận tài liệu requirement. File PDF 40 trang, toàn chữ là chữ, không hình. Mình đọc xong... không biết mình vừa đọc gì. Test case viết ra sai hết, dev phải giải thích lại từ đầu. Mất 2 ngày.
Khi đó mình mới hiểu: test case tốt bắt đầu từ việc hiểu đúng requirement, không phải từ kỹ năng tìm bug.
Nhiều bạn trái ngành lo "mình không biết code nên khó hiểu tài liệu kỹ thuật". Thật ra lo nhầm chỗ. Requirement không phải code. Đọc requirement là đọc hiểu logic nghiệp vụ - thứ mà người kế toán, giáo viên, nhân viên kinh doanh hoàn toàn có thể học được, thậm chí có lợi thế hơn người học IT thuần.
Đọc sai requirement - test case viết ra cũng sai theo
Thống kê cho thấy phần lớn (theo nhiều nghiên cứu, lên đến hơn 40-50%) lỗi phần mềm xuất phát từ việc hiểu sai hoặc bỏ sót requirement. Tức là phần lớn bug không phải do dev code sai - mà do cả team không hiểu đúng yêu cầu từ đầu. Tester là người ngăn chặn điều đó.
Requirement là gì? Các dạng tài liệu tester thường gặp
Trước khi đọc, cần biết mình đang đọc loại tài liệu gì.
User Story là dạng phổ biến nhất trong team Agile/Scrum. Cấu trúc chuẩn gồm 3 phần:
As a [ai], I want to [làm gì], so that [để đạt gì].
Ví dụ: "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 món phù hợp túi tiền.
Functional Specification (Functional Spec) - đặc tả chức năng - là tài liệu chi tiết hơn, thường do BA (Business Analyst) viết. Mô tả chính xác hệ thống phải làm gì: input là gì, output là gì, xử lý logic ra sao.
Acceptance Criteria - tiêu chí chấp nhận - là danh sách điều kiện cụ thể. Tính năng đạt khi nào thì được coi là "done". Đây là thứ tester dựa vào để confirm pass/fail.
Ba loại tài liệu này thường xuất hiện cùng nhau trong 1 sprint
Wireframe/Mockup - bản thiết kế màn hình. Không phải văn bản nhưng cũng là một dạng requirement. Tester nhìn vào đây để hiểu UI phải hiển thị gì.
Trên thực tế, team nhỏ hay startup thường gộp hết vào một file Google Doc hoặc Jira ticket. Hiểu 4 dạng trên giúp bạn đọc bất kỳ kiểu tài liệu nào mà không bị bỡ ngỡ.
Quy trình 5 bước đọc và phân tích requirement
Mình dùng quy trình này từ lúc còn là fresher đến giờ - vẫn không thay đổi, vì nó hoạt động tốt.
5 bước này áp dụng được cho cả web lẫn mobile app
Bước 1: Đọc lướt toàn bộ trước khi đọc kỹ
Đừng đọc từng dòng ngay. Đọc lướt 5-10 phút để hiểu tổng quan: tính năng này làm gì, ai dùng, kết quả mong đợi là gì. Bước này giúp bạn có "bức tranh lớn" trước khi đi vào chi tiết.
Bước 2: Xác định actor (người dùng) và luồng chính
Hỏi: Ai sẽ dùng tính năng này? Họ làm gì với nó? Kết quả họ nhận được là gì? Ví dụ với tính năng đăng ký tài khoản: actor = người dùng mới, luồng chính = nhập email + mật khẩu → nhận email xác nhận → kích hoạt tài khoản.
Bước 3: Liệt kê các luồng phụ và trường hợp ngoại lệ
Luồng chính thường chỉ chiếm 30% test case. 70% còn lại là luồng phụ và edge case. Email đã tồn tại thì sao? Mật khẩu quá ngắn? Link xác nhận hết hạn? Hỏi hết, ghi lại hết.
Bước 4: Đánh dấu những điểm mơ hồ và hỏi lại BA/Dev
Requirement không bao giờ hoàn hảo 100%. Nếu thấy câu nào không rõ - "hệ thống sẽ hiển thị thông báo phù hợp" - phù hợp là gì? Hỏi ngay. Ghi câu hỏi ra và xin clarification trước khi viết test case.
Bước 5: Mapping requirement sang test scenario
Mỗi điều kiện trong acceptance criteria = ít nhất 1 test scenario. Nếu acceptance criteria có 5 điều kiện, bạn cần tối thiểu 5 test scenario (thực tế thường nhiều hơn vì còn negative case).
Ví dụ thực tế: Phân tích requirement tính năng đăng nhập mobile app
Lý thuyết xong, mình đi vào ví dụ cụ thể. Đây là user story và acceptance criteria cho tính năng đăng nhập - thứ hầu như app nào cũng có.
User Story:
As a registered user, I want to log in to the app using my email and password, so that I can access my personal account.
Acceptance Criteria:
- Hiển thị form với 2 field: Email và Password
- Password được ẩn bằng dấu chấm, có icon show/hide
- Nhấn "Đăng nhập" với thông tin đúng → vào màn hình Home
- Thông tin sai → hiển thị thông báo lỗi
- Đăng nhập thành công → lưu session, không cần đăng nhập lại khi mở app
Từ 5 acceptance criteria này, mình derive được hơn 15 test scenario
Sau khi đọc xong, mình tự đặt câu hỏi:
- "Thông báo lỗi" ở điều kiện 4 hiển thị chữ gì chính xác?
- Sai email hay sai password thì thông báo có khác nhau không?
- Sau bao nhiêu lần nhập sai thì bị khóa tài khoản?
- Session lưu bao lâu? Người dùng có thể tự đăng xuất không?
- Bàn phím điện thoại tự hiện khi focus vào field không?
- Điều gì xảy ra nếu người dùng nhấn "Đăng nhập" khi field trống?
Nhìn lại: acceptance criteria có 5 điều kiện, nhưng từ đó mình derive ra 6 câu hỏi chưa có câu trả lời. Đây là những câu hỏi mình cần hỏi BA trước khi viết test case. Nếu không hỏi, test case sẽ bỏ sót các trường hợp quan trọng - và bug sẽ nổ production.
Những lỗi phổ biến khi fresher đọc requirement
Mình quan sát nhiều bạn mới vào nghề mắc phải 4 lỗi này. Biết trước để tránh.
Lỗi 1: Chỉ test happy path
Happy path là luồng "mọi thứ đúng như kỳ vọng". Nhiều fresher chỉ test đúng - pass, sai - fail rồi cho là xong. Thật ra bug thường ẩn ở chỗ người dùng làm điều bất ngờ: copy-paste email có khoảng trắng, nhập emoji vào ô số điện thoại, bấm back giữa chừng. Requirement phải khai thác hết các hướng đó.
Lỗi 2: Không đọc phần "non-functional"
Functional requirement = hệ thống làm gì. Non-functional requirement = hệ thống làm tốt đến mức nào. Ví dụ: "Trang load trong 3 giây", "Hỗ trợ 1000 user đồng thời", "Hoạt động trên iOS 14 trở lên". Bỏ qua phần này là bỏ qua cả một nhóm test quan trọng.
Happy path vs edge case - tester giỏi không bỏ qua cái nào
Lỗi 3: Không đặt câu hỏi khi không hiểu
Ngại hỏi là lỗi nguy hiểm nhất. Nhiều bạn sợ "hỏi ngớ ngẩn" nên tự diễn giải. Kết quả: viết test case theo cách hiểu sai, tốn công làm lại. Không có câu hỏi nào ngớ ngẩn khi mục tiêu là hiểu đúng requirement. BA viết tài liệu cũng không phải lúc nào cũng rõ ràng 100%.
Lỗi 4: Đọc requirement chỉ 1 lần
Requirement thay đổi. Trong sprint, BA hoặc PM có thể update tài liệu. Tester cần kiểm tra lại requirement trước khi bắt đầu test, đặc biệt sau khi dev fix bug - đôi khi scope thay đổi nhỏ kéo theo test case phải update.
Checklist phân tích requirement - tải về dùng ngay
Sau nhiều sprint làm việc, mình đúc kết thành checklist này. Mỗi lần nhận requirement mới, mình chạy qua danh sách này trước khi viết test case.
Checklist gồm 3 nhóm câu hỏi:
Nhóm 1 - Hiểu tổng quan:
- Tính năng này phục vụ ai? (actor)
- Mục tiêu nghiệp vụ là gì?
- Tính năng nằm ở đâu trong flow tổng thể của app?
Nhóm 2 - Chi tiết chức năng:
- Acceptance criteria có đầy đủ input/output không?
- Có điều kiện nào mơ hồ cần clarify không?
- Luồng lỗi (error flow) đã được mô tả chưa?
- Validation rule cho từng field là gì?
- Có màn hình/trạng thái nào chưa được mô tả không?
Nhóm 3 - Non-functional và tích hợp:
- Tính năng này tích hợp với hệ thống nào khác?
- Có yêu cầu về performance không?
- Tương thích thiết bị/OS version nào?
- Có yêu cầu bảo mật đặc biệt không?
Checklist ngắn nhưng giúp không bỏ sót câu hỏi quan trọng
Mình đã đóng gói checklist này vào file tải về. Bạn có thể in ra hoặc lưu vào Notion để dùng mỗi sprint. Tải tại đây: Tải checklist phân tích requirement (HTML)
Nếu bạn muốn đi sâu hơn vào toàn bộ quy trình kiểm thử - từ đọc requirement, viết test case, đến báo bug - khóa Kiểm thử phần mềm cover chi tiết từng phần, thiết kế riêng cho người mới bắt đầu không cần nền tảng IT.
Đọc requirement không cần biết code - và đây là lợi thế của bạn
Mình muốn nói thẳng với bạn đang trái ngành: không biết code khi đọc requirement không phải bất lợi.
Requirement mô tả nghiệp vụ, không phải kỹ thuật. Người từng làm kế toán hiểu rất rõ flow hóa đơn, xử lý hoàn tiền, điều kiện chiết khấu - những thứ dev code xong vẫn có thể sai vì họ không hiểu nghiệp vụ. Người từng làm chăm sóc khách hàng hiểu người dùng thật sự dùng app như thế nào, chỗ nào gây nhầm lẫn. Đó là lợi thế tester trái ngành thường có hơn người học IT thuần.
Thứ bạn cần học thêm không nhiều:
- Hiểu các dạng tài liệu requirement (đã cover trong bài)
- Đặt câu hỏi đúng chỗ (kỹ năng học được)
- Template để không bỏ sót (checklist bên trên)
Lợi thế trái ngành: hiểu nghiệp vụ sâu hơn nhiều bạn học IT thuần
Thấy khó ở bước đọc functional spec bình thường. Mình cũng mất 2-3 sprint đầu mới quen với ngôn ngữ tài liệu. Nhưng một khi quen rồi - kỹ năng này không lỗi thời, không bị AI thay thế, và là thứ phân biệt tester giỏi với tester trung bình.
Test kỹ bắt đầu từ hiểu đúng. Bắt đầu từ requirement.