Đọc Requirement & Viết Test Scenario: Kỹ Năng Cốt Lõi Tester Không Code

7 tháng trước · 14 phút đọc

Tại sao requirement lại làm tester mới bối rối?

Mình nhớ lần đầu nhận tài liệu requirement dày 40 trang của một dự án ngân hàng. Không có hình ảnh, toàn chữ, đọc đến trang 5 là không hiểu mình cần test cái gì. Cảm giác đó rất phổ biến, đặc biệt với bạn trái ngành.

Vấn đề không phải bạn thiếu kiến thức IT. Vấn đề là chưa biết đọc requirement theo góc nhìn tester. Dev đọc requirement để biết cần code gì. Tester đọc requirement để biết cần kiểm tra gì - hai mục tiêu khác nhau hoàn toàn.

342169 Dev và tester đọc cùng 1 tài liệu nhưng tìm hai thứ khác nhau

Bài này mình sẽ hướng dẫn bạn từng bước: từ mở tài liệu requirement lần đầu đến viết được test scenario hoàn chỉnh. Case thực hành là tính năng chuyển khoản ngân hàng - quen thuộc, dễ hiểu, và thực tế đủ để bạn áp dụng ngay khi đi làm.

Không cần biết code. Chỉ cần đọc kỹ và có tư duy logic.

Requirement document là gì và có những loại nào?

Requirement document - tài liệu yêu cầu phần mềm - là tài liệu mô tả hệ thống cần làm gì. Hiểu đơn giản: đây là "đơn đặt hàng" của khách hàng gửi cho team phát triển.

Trong công việc thực tế, bạn sẽ gặp 3 dạng phổ biến:

BRD (Business Requirement Document): Tài liệu yêu cầu nghiệp vụ. Dày, nhiều chữ, góc nhìn kinh doanh. Ví dụ: "Hệ thống cần cho phép khách hàng chuyển khoản liên ngân hàng trong vòng 30 giây."

SRS (Software Requirement Specification): Tài liệu đặc tả kỹ thuật. Chi tiết hơn BRD, có điều kiện cụ thể, luồng xử lý. Đây là tài liệu tester hay làm việc nhất.

User Story: Dạng ngắn gọn dùng trong Agile/Scrum. Format: "Là [người dùng], tôi muốn [hành động] để [mục đích]." Ví dụ: "Là khách hàng cá nhân, tôi muốn chuyển khoản bằng số điện thoại để không cần nhớ số tài khoản."

342170 Ba dạng requirement phổ biến - mỗi dạng có độ chi tiết khác nhau

Trái ngành hay lo "không đọc được tài liệu kỹ thuật". Thực ra BRD và User Story viết bằng ngôn ngữ thường ngày, không code. SRS có thể phức tạp hơn, nhưng phần tester cần quan tâm chỉ là: điều kiện đầu vào, luồng xử lý, kết quả đầu ra. Ba thứ đó không cần biết code mới hiểu được.

Checklist 5 bước đọc requirement hiệu quả

Bước đầu tiên: Đọc một lượt từ đầu đến cuối, không ghi chú. Nhiều người hay vừa đọc vừa highlight ngay, kết quả là highlight tất cả vì chưa hiểu thứ gì quan trọng. Đọc lướt lần đầu để nắm bức tranh tổng thể: tính năng này làm gì, ai dùng, mục đích là gì.

Bước hai: Xác định actor - người dùng trong tính năng. Actor là ai sẽ tương tác với hệ thống. Một tính năng có thể có nhiều actor. Ví dụ tính năng chuyển khoản ngân hàng có: khách hàng cá nhân, khách hàng doanh nghiệp, admin ngân hàng. Mỗi actor có luồng khác nhau.

Bước ba: Vẽ sơ đồ luồng chính (happy path). Dùng giấy và bút, vẽ các bước người dùng thực hiện khi mọi thứ diễn ra bình thường. Không cần đẹp, chỉ cần đúng thứ tự. Bước này giúp bạn hình dung tính năng trước khi nghĩ đến test.

342171 5 bước đọc requirement - bước 4 và 5 là nơi tester tạo ra giá trị thật sự

Bước bốn: Tìm điều kiện và ràng buộc. Đây là phần quan trọng nhất với tester. Trong tài liệu, tìm các từ khóa: "phải", "không được", "tối đa", "tối thiểu", "nếu... thì...", "chỉ khi". Ví dụ: "Số tiền chuyển khoản tối thiểu 10.000đ, tối đa 500 triệu/giao dịch" - câu này cho bạn ngay 2-3 test case về giới hạn số tiền.

Bước năm: Liệt kê điều requirement CHƯA nói. Đây là kỹ năng phân biệt tester junior và senior. Requirement không bao giờ viết đủ hết. Ví dụ requirement nói "người dùng nhập số tài khoản" nhưng không nói xảy ra gì nếu số tài khoản là chữ, hoặc để trống, hoặc đúng định dạng nhưng tài khoản không tồn tại. Những "khoảng trắng" này là nơi bug hay ẩn náu.

Tải checklist 5 bước này về để dùng mỗi khi nhận requirement mới: Tải Checklist 5 Bước Đọc Requirement

Thực hành: Đọc requirement chuyển khoản ngân hàng

Mình lấy một đoạn requirement thực tế từ dự án ngân hàng (đã ẩn thông tin):

Tính năng: Chuyển khoản nội bộ

Khách hàng có thể chuyển khoản sang tài khoản cùng ngân hàng.

Số tiền tối thiểu: 10.000 VNĐ. Tối đa: 500.000.000 VNĐ/giao dịch.

Số dư tài khoản nguồn phải lớn hơn số tiền chuyển cộng phí giao dịch.

Phí giao dịch: 0 VNĐ với tài khoản premium, 5.000 VNĐ với tài khoản thường.

Nội dung chuyển khoản: tối đa 200 ký tự, cho phép chữ và số, không cho phép ký tự đặc biệt.

Giao dịch thành công hiển thị màn hình xác nhận, gửi SMS và email thông báo.

Áp dụng ngay bước 4 - tìm điều kiện:

"Tối thiểu 10.000" → test với 9.999, 10.000, 10.001
"Tối đa 500 triệu" → test với 499.999.999, 500.000.000, 500.000.001
"Số dư phải lớn hơn" → test khi số dư vừa đủ, thiếu 1đ, thiếu đúng phí
"Tài khoản premium" vs "tài khoản thường" → hai actor khác nhau, hai kết quả khác nhau
"Không cho phép ký tự đặc biệt" → test với @, #, &, emoji

342172 Chỉ 6 dòng requirement đã cho ra hơn 15 test scenario khác nhau

Bước 5 - tìm khoảng trắng requirement chưa nói:

Chuyện gì xảy ra nếu số tài khoản đích không tồn tại?
Nếu tài khoản đích bị khóa?
Nếu nhập đúng số dư nhưng trong lúc đang xác nhận thì có giao dịch khác chạy, số dư thay đổi?
SMS và email gửi thất bại thì giao dịch có được tính là thành công không?

Những câu hỏi này bạn cần hỏi BA (Business Analyst) hoặc PM để làm rõ trước khi viết test case. Đây là phần tester tạo ra giá trị thực sự - không phải chỉ test những gì đã viết, mà còn tìm những gì chưa được viết.

Test scenario là gì và khác test case ở điểm nào?

Test scenario là một câu mô tả tình huống cần kiểm tra. Ngắn gọn, ở mức cao, tập trung vào "cần kiểm tra điều gì".

Test case là phiên bản chi tiết của test scenario: có bước thực hiện cụ thể, dữ liệu đầu vào, kết quả mong đợi.

	Test Scenario	Test Case
Độ dài	1-2 câu	Nhiều bước chi tiết
Mức chi tiết	Cao, tổng quát	Thấp, cụ thể
Viết khi nào	Đọc xong requirement	Sau khi có scenario
Ai viết	Tester (thường)	Tester
Dùng để	Bao phủ phạm vi	Thực hiện test

342173 Test scenario và test case - hai tầng của cùng một quy trình

Ví dụ cụ thể với tính năng chuyển khoản:

Test scenario: "Kiểm tra hành vi hệ thống khi số tiền chuyển khoản vượt quá giới hạn tối đa."

Test case từ scenario đó:

Bước 1: Đăng nhập tài khoản có số dư 1 tỷ
Bước 2: Vào màn hình chuyển khoản nội bộ
Bước 3: Nhập số tài khoản đích hợp lệ
Bước 4: Nhập số tiền 500.000.001 VNĐ
Bước 5: Nhấn "Chuyển khoản"
Kết quả mong đợi: Hệ thống hiển thị thông báo lỗi "Số tiền vượt quá giới hạn tối đa 500.000.000 VNĐ/giao dịch", không thực hiện giao dịch

Bạn thấy không - test scenario ngắn 1 câu, test case chi tiết 5 bước cộng expected result. Khi mới bắt đầu, hãy viết scenario trước. Scenario đủ tốt thì test case viết sẽ nhanh hơn nhiều.

Cách viết test scenario từ requirement - công thức đơn giản

Một test scenario tốt cần trả lời đủ 3 câu hỏi: Ai làm? Làm gì? Trong điều kiện nào?

Công thức: [Actor] [hành động] khi [điều kiện]

Ví dụ áp dụng với requirement chuyển khoản:

✅ "Khách hàng thường chuyển khoản thành công khi số dư đủ và số tiền trong giới hạn cho phép"
✅ "Khách hàng thường bị từ chối chuyển khoản khi số tiền nhỏ hơn 10.000 VNĐ"
✅ "Khách hàng premium chuyển khoản thành công và không bị trừ phí giao dịch"
✅ "Hệ thống hiển thị lỗi khi nội dung chuyển khoản chứa ký tự đặc biệt"

Từ 6 dòng requirement, mình viết được ít nhất 12 scenario:

Nhóm Happy Path (luồng thành công):

Khách hàng thường chuyển khoản thành công
Khách hàng premium chuyển khoản thành công (không phí)
Hệ thống gửi SMS và email sau giao dịch thành công

Nhóm Validation (kiểm tra đầu vào): 4. Từ chối khi số tiền < 10.000 VNĐ 5. Từ chối khi số tiền > 500.000.000 VNĐ 6. Từ chối khi số dư không đủ (bao gồm phí) 7. Từ chối khi nội dung chứa ký tự đặc biệt 8. Từ chối khi nội dung vượt 200 ký tự

Nhóm Edge Case (trường hợp biên): 9. Chuyển khoản đúng 10.000 VNĐ (ranh giới tối thiểu) 10. Chuyển khoản đúng 500.000.000 VNĐ (ranh giới tối đa) 11. Số dư đúng bằng số tiền + phí (không dư một đồng) 12. Nội dung đúng 200 ký tự (ranh giới tối đa)

342174 3 nhóm scenario bao phủ toàn bộ tính năng từ happy path đến edge case

Nhóm Edge Case (trường hợp biên) là nơi bug hay xuất hiện nhất. Dev thường test happy path là xong, tester giỏi test ranh giới - đúng 10.000 chứ không phải 10.001.

Tải template Excel để tổ chức toàn bộ scenario theo format chuẩn: Tải Template Excel Test Scenario

Những lỗi phổ biến khi viết test scenario lần đầu

Ba lỗi mình thấy nhiều nhất ở người mới:

Lỗi 1: Viết scenario quá chung, không test được. "Kiểm tra tính năng chuyển khoản hoạt động đúng" - câu này vô nghĩa vì không rõ "đúng" là gì. Phải cụ thể: "Khách hàng chuyển khoản thành công khi nhập đủ thông tin hợp lệ và số dư đủ".

Lỗi 2: Bỏ qua actor. Cùng một hành động nhưng actor khác nhau thì kết quả khác nhau. "Chuyển khoản thành công" khác với "Khách hàng premium chuyển khoản thành công không phí". Luôn ghi rõ ai thực hiện.

Lỗi 3: Chỉ test happy path. Nhiều bạn viết 5-6 scenario đều là "thành công khi...". Bug thường ẩn trong validation và edge case. Tỉ lệ mình khuyến nghị: 20% happy path, 40% validation, 40% edge case.

342175 3 lỗi phổ biến và cách sửa - lỗi 3 là nguyên nhân hay bỏ sót bug nhất

Mình biết phần edge case nghe có vẻ khó nghĩ ra. Một mẹo nhanh: với mỗi điều kiện trong requirement có con số hoặc giới hạn, tự hỏi "số đúng bằng giới hạn thì sao?", "số lớn hơn 1 đơn vị thì sao?", "số nhỏ hơn 1 đơn vị thì sao?". Ba câu đó cho bạn ít nhất 3 edge case mỗi điều kiện.

Thấy khó ở phần này là hoàn toàn bình thường. Mình mất khoảng 2-3 tuần thực hành mới nghĩ ra edge case tốt một cách tự nhiên. Không cần kỹ năng IT - chỉ cần tư duy "điều gì có thể sai?" và rèn luyện dần.

Bắt đầu từ đâu nếu bạn chưa có requirement thật?

Câu hỏi mình hay nhận nhất từ bạn đang học: "Mình chưa đi làm, lấy requirement thật ở đâu để luyện?"

Ba nguồn bạn có thể dùng ngay:

1. App thật quanh bạn. Shopee, Grab, Agribank, VCB Digibank - đây đều là sản phẩm thật với tính năng thật. Tự đóng vai tester: mở app, chọn 1 tính năng, tự viết requirement dựa trên những gì bạn thấy, rồi từ đó viết scenario. Ví dụ: tính năng nạp tiền điện thoại trên Agribank E-Mobile Banking - bạn tự liệt kê điều kiện, giới hạn, luồng xử lý dựa trên app thật.

2. Các website demo và practice. Có nhiều web được tạo ra để tester luyện tập. Tìm kiếm "testing practice website" hoặc tham khảo: Các website luyện tập testing miễn phí

3. Open source project trên GitHub. Tìm project có README mô tả tính năng, đọc mô tả đó như đọc requirement, rồi viết scenario.

342176 App ngân hàng thật quanh bạn là kho requirement vô tận để luyện tập

Mình khuyến nghị bắt đầu với Agribank hoặc VCB Digibank vì đây là app nhiều người Việt dùng, tính năng đa dạng (chuyển khoản, nạp tiền, thanh toán hóa đơn), và bạn có thể test ngay trên điện thoại mà không cần môi trường đặc biệt.

Mục tiêu tuần đầu: viết được 10 scenario cho 1 tính năng. Không cần đẹp, không cần đầy đủ. Cần bắt đầu.

Testing không phải kỹ năng bẩm sinh - là kỹ năng rèn luyện được. Bạn đọc đến đây đã hiểu requirement là gì, cách đọc 5 bước, công thức viết scenario, và biết tránh 3 lỗi phổ biến. Đủ để bắt đầu thực hành rồi.

Comment bên dưới tính năng bạn muốn luyện viết scenario đầu tiên - mình đọc và góp ý từng bạn.