Software Requirements Specification (SRS) mô tả hệ thống cần làm gì, các ràng buộc và tiêu chí chất lượng mà hệ thống phải đáp ứng. Với tester, SRS là một test basis quan trọng để xác định test conditions và thiết kế test cases.
Ai viết SRS?
Không có một vai trò duy nhất luôn viết SRS. Tùy tổ chức, người chịu trách nhiệm có thể là Business Analyst, System Analyst, Product Owner, Product Manager hoặc kỹ sư yêu cầu.
Các thành phần chính của SRS
- Mục đích, phạm vi và bối cảnh hệ thống.
- Stakeholders, user roles và glossary.
- Functional requirements và business rules.
- Non-functional requirements. (nếu có)
- External interfaces: UI, API, hardware và hệ thống khác.
- Data requirements, validation và retention.
- Constraints, assumptions, dependencies và acceptance criteria.
Functional và Non-functional Requirements
| Loại | Câu hỏi | Ví dụ |
|---|---|---|
| Functional | Hệ thống phải làm gì? | Người dùng có thể đặt lại mật khẩu qua email |
| Non-functional | Hệ thống phải làm tốt đến mức nào? | Hệ thống chịu tải được 100.000 user đăng nhập cùng lúc |
Hai nhóm này có thể nằm trong cùng một SRS hoặc tài liệu riêng. Điều quan trọng là requirement phải cụ thể và đo đếm được.
“95% request phản hồi dưới 2 giây với 500 người dùng đồng thời” -> testable hơn, mạch lạc hơn
Non-functional: mọi lần khóa tài khoản phải được ghi audit log và lưu tối thiểu 12 tháng.
Làm gì khi không có SRS hoặc SRS sơ sài?
Tình trạng này rất hay gặp tại VN 😅Không có SRS không có nghĩa tester phải dừng hoàn toàn, nhưng cũng không nên âm thầm tự đoán requirement. Hãy xây dựng test basis từ các nguồn thay thế:
- User stories, acceptance criteria, prototype và thiết kế UI.
- API specification, database model, business rules và hợp đồng.
- Trao đổi với PO, BA, user, developer và các team business trong công ty
- Hành vi của phiên bản cũ đã hoạt động ổn định
Viết test case từ SRS như thế nào?
- Review SRS: tìm điểm thiếu, mơ hồ, mâu thuẫn và không testable.
- Xác định test conditions: chức năng, business rule, interface, data và quality characteristics cần kiểm tra.
- Chọn test technique: EP/BVA cho miền dữ liệu, Decision Table cho tổ hợp rule, State Transition cho hành vi phụ thuộc trạng thái.
- Thiết kế test cases: precondition, steps, test data và expected result cụ thể.
- Thêm negative và non-functional tests: không chỉ happy path.
- Tạo traceability: liên kết requirement ID với test cases để đo coverage và đánh giá impact khi requirement đổi.
- Review và ưu tiên: ưu tiên theo risk, business value và dependency.
Kết luận
Một SRS tốt tạo hiểu biết chung chứ không chỉ để “đủ hồ sơ”. Khi tài liệu chưa đủ, tester cần chủ động làm rõ và ghi nhận assumption. Khi tài liệu tốt, hãy dùng test techniques và traceability để biến requirement thành một bộ test nhỏ nhưng có coverage rõ ràng.
