Đọc Hiểu Requirement: Kỹ Năng Tester Không Code Cần Thành Thạo
6 tháng trước · 13 phút đọc
Tại sao đọc requirement là kỹ năng sống còn của tester?
Mình nhớ lần đầu nhận task test tính năng đăng ký tài khoản. Requirement viết ngắn gọn: "Người dùng nhập email, mật khẩu và nhấn đăng ký." Mình đọc xong, gật đầu, viết ngay 3 test case: nhập đúng thì pass, nhập sai thì fail, bỏ trống thì báo lỗi. Xong.
Kết quả? Sprint review, dev hỏi: "Bạn test chưa case email trùng rồi?" Mình đứng hình. Rồi leader hỏi thêm: "Còn email có khoảng trắng ở đầu? Còn password dài 200 ký tự?" Mình không test cái nào hết. Bug nổ production sau đó 2 ngày.
Vấn đề không phải mình thiếu kỹ năng testing. Vấn đề là mình đọc requirement theo kiểu "đọc cho có" - hiểu nghĩa bề mặt, không phân tích sâu. Đây là lỗi phổ biến nhất của fresher tester trái ngành, và bài này mình sẽ chỉ từng bước để không lặp lại sai lầm đó.
Đọc qua loa requirement = viết thiếu test case = bug nổ production
Thống kê cho thấy 50% (Inspecting Requirements by Wiegers) lỗi phần mềm bắt nguồn từ việc hiểu sai hoặc bỏ sót requirement ngay từ đầu. Con số này nhắc nhở: test kỹ bắt đầu từ trước khi mở Jira viết test case.
User story là gì và tester đọc nó như thế nào?
User story là cách team Agile viết requirement theo góc nhìn người dùng. Format chuẩn trông như thế này:
Là [vai trò người dùng], tôi muốn [hành động], để [mục đích/lợi ích].
Ví dụ thực tế: "Là khách hàng, tôi muốn lọc sản phẩm theo giá, để tìm sản phẩm phù hợp ngân sách nhanh hơn."
Nhìn bề ngoài thì đơn giản. Nhưng với tester, mỗi user story là một bài toán phân tích, không phải một câu chuyện để đọc.
Ba phần của user story - mỗi phần gợi ra câu hỏi khác nhau cho tester
Cách mình đọc user story - 3 câu hỏi bắt buộc:
Câu 1: "Ai" dùng tính năng này? - Khách hàng thường, khách VIP, hay admin? Mỗi vai trò có thể có quyền hạn khác nhau. Ví dụ: khách hàng thường lọc giá tối đa 5 triệu, admin nhìn thấy toàn bộ range.
Câu 2: "Muốn" gì - cụ thể đến đâu? - "Lọc theo giá" có nghĩa là kéo thanh trượt? Nhập tay giá min/max? Hay chọn từ dropdown preset? Nếu không rõ, đây là lúc hỏi, không phải lúc tự đoán.
Câu 3: "Để" làm gì - có đo được không? - Mục đích "tìm nhanh hơn" thì nhanh hơn bao nhiêu? Có performance requirement không? Câu hỏi này thường lộ ra acceptance criteria bị thiếu.
Ba câu hỏi này chạy trong đầu mình mỗi lần đọc user story. Không cần nhớ thuộc lòng, cứ thực hành vài lần là tự nhiên.
Các bước phân tích requirement để viết test scenario
Mình dùng quy trình 5 bước này từ khi còn là tester năm 2, và đến giờ vẫn không thay đổi nhiều. Không phức tạp, nhưng cần làm đủ hết.
Bước 1: Đọc lần 1 - hiểu toàn cảnh
Đọc toàn bộ requirement từ đầu đến cuối, không viết gì hết. Mục tiêu: nắm được tính năng này làm gì, ai dùng, nằm trong luồng nào của hệ thống. Bước này mất 5-10 phút.
Bước 2: Đọc lần 2 - đánh dấu điểm mờ
Lần này cầm bút (hoặc dùng highlight), đánh dấu mọi chỗ mơ hồ, thiếu thông tin, hoặc có thể hiểu theo nhiều cách. Ví dụ: "email hợp lệ" - hợp lệ theo tiêu chuẩn nào? Có check domain không?
Bước 3: Hỏi trước khi viết
Danh sách câu hỏi từ bước 2, gửi cho BA (business analyst) hoặc product owner. Đừng tự đoán. Mình từng tự đoán "email không cần verify domain" vì requirement không nói rõ - kết quả là pass test case nhưng fail UAT (kiểm thử chấp nhận - user acceptance testing) vì khách hàng yêu cầu ngược lại.
Bước 4: Xác định boundary và edge case
Sau khi hiểu rõ, bắt đầu vẽ ra các trường hợp:
- Happy path: luồng chính, người dùng làm đúng mọi thứ
- Negative case: nhập sai, bỏ trống, vượt giới hạn
- Edge case: giá trị biên (boundary), ký tự đặc biệt, khoảng trắng, độ dài tối đa/tối thiểu
Bước 5: Viết test scenario trước, test case sau
Nhiều fresher nhảy thẳng vào viết test case chi tiết. Mình khuyên viết test scenario (kịch bản tổng quát) trước để đảm bảo bao phủ đủ, sau đó mới chi tiết hóa từng bước.
5 bước liên tiếp - bỏ bước nào cũng hỏng cả quy trình
Ví dụ: tính năng "lọc sản phẩm theo giá", test scenario bao gồm:
- Lọc với giá min < max - kết quả đúng
- Lọc với giá min = max - chỉ hiện sản phẩm đúng giá đó
- Lọc với giá min > max - báo lỗi hay swap tự động?
- Nhập chữ vào ô giá - validate thế nào?
- Giá âm - có chặn không?
- Giá = 0 - hiển thị gì?
Sáu scenario từ 1 user story đơn giản. Test case chi tiết sẽ có nhiều hơn nữa.
5 sai lầm fresher trái ngành hay mắc khi đọc requirement
Mình đào tạo khá nhiều bạn chuyển ngành vào testing. Có 5 lỗi mình thấy lặp đi lặp lại - không phải vì các bạn thiếu năng lực, mà vì chưa có thói quen tư duy như tester.
Nhận ra lỗi sớm thì sửa nhanh - đừng đợi đến lúc bug nổ
Lỗi 1: Chỉ test happy path
Happy path là luồng "người dùng làm đúng mọi thứ". Fresher thường test xong happy path rồi báo done. Thực tế, phần lớn bug nghiêm trọng nằm ở negative case và edge case - những gì người dùng làm sai hoặc bất ngờ.
Lỗi 2: Tự hiểu thay vì hỏi
Gặp chỗ mơ hồ, nhiều bạn tự đoán theo logic "thường thì thế". Testing không có chỗ cho "thường thì". Mỗi assumption chưa được confirm là một rủi ro.
Lỗi 3: Không đọc acceptance criteria
User story thường kèm acceptance criteria - tiêu chí để tính năng được chấp nhận. Đây là "đáp án" của requirement. Bỏ qua phần này là bỏ qua nơi BA đã tư duy sẵn các trường hợp quan trọng.
Lỗi 4: Không check dependency
Tính năng A có thể phụ thuộc vào tính năng B. Ví dụ: test "lọc theo giá" nhưng không check nó ảnh hưởng gì đến "sắp xếp theo giá" đang có sẵn. Hai tính năng chạy song song nhau có xung đột không?
Lỗi 5: Copy requirement làm test case
Viết test case kiểu: "Nhập email hợp lệ → Kết quả: đăng ký thành công" - đây là paraphrase requirement, không phải test case. Test case cần có dữ liệu cụ thể: email nào, password nào, expected result là gì chính xác trên màn hình.
Thấy mình đang mắc lỗi nào không? Bình thường. Mình từng mắc cả 5.
Requirement document so với user story: đọc khác nhau thế nào?
Không phải team nào cũng viết requirement theo dạng user story. Nhiều dự án - đặc biệt là outsource hoặc dự án ngân hàng, bảo hiểm - vẫn dùng Software Requirement Specification (SRS) hoặc Functional Specification Document (FSD): tài liệu dài, nhiều chương, nhiều bảng biểu.
Hai dạng requirement khác nhau - cách đọc cũng khác
| Tiêu chí | User Story | SRS/FSD |
|---|---|---|
| Độ dài | 1-5 câu | 10-100+ trang |
| Ngôn ngữ | Thông thường, phi kỹ thuật | Kỹ thuật, formal |
| Acceptance criteria | Thường có (Given/When/Then) | Nằm rải rác trong tài liệu |
| Dependency | Ít khi ghi rõ | Thường có section riêng |
| Khi bị mơ hồ | Hỏi PO/BA | Đọc cross-reference, hỏi BA |
Khi đọc SRS/FSD, mình làm theo thứ tự sau:
- Đọc mục "Purpose" và "Scope" trước - biết tài liệu này cover cái gì
- Tìm glossary (bảng thuật ngữ) - đọc kỹ định nghĩa từng khái niệm trong hệ thống
- Đọc use case diagram hoặc flow diagram nếu có - visual giúp hiểu nhanh hơn text
- Sau đó mới đọc từng functional requirement theo flow
Lưu ý: SRS thường dùng từ "shall" (bắt buộc) và "should" (nên có). "Shall" = tester phải test. "Should" = confirm với BA xem có nằm trong scope sprint này không.
Dù là user story hay SRS, nguyên tắc chung không đổi: đọc để tìm lỗ hổng, không phải đọc để hiểu. Hai kiểu đọc này khác nhau hoàn toàn.
Template phân tích requirement: tải miễn phí và dùng ngay
Mình tổng hợp lại quy trình 5 bước thành một template để bạn điền vào khi nhận requirement mới. Dùng ngay từ sprint đầu tiên, không cần chờ "quen việc" mới làm.
Template gồm các phần:
- Thông tin requirement: tên tính năng, user story ID, sprint
- Câu hỏi cần hỏi BA: danh sách chỗ mơ hồ chưa rõ
- Phân tích boundary: giá trị min/max, điều kiện biên
- Danh sách test scenario: happy path, negative, edge case
- Dependency check: tính năng nào liên quan cần regression testing
Template giúp không bỏ sót - quan trọng hơn là tạo thói quen tư duy có hệ thống
Tải template tại đây: Tải Template Phân Tích Requirement (.html)
Cách dùng template hiệu quả nhất: điền ngay khi đọc requirement lần 2. Không cần hoàn chỉnh 100% trước khi hỏi BA - mang nó vào cuộc họp, điền thêm trong lúc nói chuyện.
Một bạn trong nhóm mình hướng dẫn nói: "Lúc đầu điền template mất 30 phút cho 1 user story. Sau 2 tuần còn 10 phút. Sau 1 tháng thì không cần template nữa vì đã thành thói quen." Đúng vậy. Template là bánh xe tập - dùng rồi sẽ tự đi được.
Nếu bạn muốn học bài bản hơn về 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 tại F8 cover chi tiết từng phần, phù hợp cho người mới hoàn toàn không cần biết code.
Thực hành ngay: phân tích 1 user story từ đầu đến cuối
Đọc lý thuyết chưa đủ. Mình làm mẫu 1 lần để bạn thấy quy trình chạy như thế nào trong thực tế.
User story mẫu: "Là người dùng đã đăng nhập, tôi muốn thay đổi mật khẩu, để bảo mật tài khoản tốt hơn."
Bước 1 - Đọc toàn cảnh: Tính năng đổi mật khẩu, chỉ dành cho user đã login. Nằm trong module account/profile.
Bước 2 - Đánh dấu điểm mờ:
- "Mật khẩu" - có rule không? Độ dài tối thiểu? Phải có chữ hoa/số/ký tự đặc biệt?
- Có cần nhập mật khẩu cũ để xác nhận không?
- Sau đổi thành công, user bị logout session cũ không?
- Đổi bao nhiêu lần/ngày được phép?
Bước 3 - Câu hỏi gửi BA: Gửi 4 câu hỏi trên. Giả sử BA xác nhận: mật khẩu min 8 ký tự, phải nhập mật khẩu cũ, sau đổi logout session khác (không logout session hiện tại).
Bước 4 - Test scenario:
| Loại | Scenario |
|---|---|
| Happy path | Nhập đúng pass cũ + pass mới đủ 8 ký tự → Đổi thành công |
| Negative | Pass cũ sai → Báo lỗi rõ ràng |
| Negative | Pass mới < 8 ký tự → Validate ngay |
| Negative | Pass mới = pass cũ → Có thông báo không? |
| Edge | Pass mới dài 255 ký tự - có accept không? |
| Edge | Pass mới toàn ký tự đặc biệt như !@#$% |
| Edge | Đổi xong, session khác có bị logout không? |
7 scenario từ 1 user story 2 dòng - đây mới là test kỹ
Từ 1 user story 2 dòng ra 7 scenario. Và sau khi BA confirm thêm, sẽ còn nhiều hơn. Đây là tư duy tester - không đọc để hiểu, đọc để tìm lỗ hổng.
Mình biết quy trình này nghe có vẻ nhiều bước với người mới. Nhưng thực hành vài sprint là chạy tự nhiên. Quan trọng là bắt đầu ngay từ sprint đầu, đừng đợi "quen việc" mới làm đúng - vì thói quen xấu hình thành rất nhanh.
Bài tiếp mình sẽ hướng dẫn viết test case chi tiết từ các scenario này - bao gồm cả cách điền expected result thế nào để developer reproduce được bug. Bookmark để không bỏ lỡ nhé!