Có phải mọi dự án đều nên dùng cùng một test process, cùng số lượng test case và cùng mức độ automation? Không. Theo ISTQB, testing không được thực hiện một cách biệt lập mà là một phần của development process và phải phục vụ nhu cầu kinh doanh của stakeholder.

Test Process in Context có nghĩa là test process phải được điều chỉnh theo bối cảnh thực tế của sản phẩm, con người và tổ chức.

Vì sao bối cảnh lại quan trọng?

Testing được stakeholder đầu tư ngân sách với mục tiêu cuối cùng là hỗ trợ đáp ứng business needs. Vì vậy, một quy trình kiểm thử tốt không phải quy trình có nhiều tài liệu hoặc nhiều test case nhất, mà là quy trình phù hợp với mục tiêu, rủi ro và nguồn lực của dự án.

Cùng là một chức năng thanh toán, ứng dụng thử nghiệm nội bộ và hệ thống ngân hàng không thể có cùng yêu cầu coverage, mức độ độc lập, bằng chứng kiểm thử hay quy trình báo cáo.

8 yếu tố ảnh hưởng đến Test Process

1. Stakeholders

Nhu cầu, kỳ vọng, requirement và mức độ hợp tác của stakeholder ảnh hưởng trực tiếp đến test objectives và cách báo cáo. Product Owner có thể cần feedback nhanh theo từng Sprint, trong khi khách hàng doanh nghiệp lại yêu cầu test evidence và biên bản nghiệm thu đầy đủ.

2. Team members

Skills, kiến thức, kinh nghiệm, khả năng sẵn sàng và nhu cầu đào tạo của thành viên quyết định cách phân công và mức độ phức tạp của hoạt động kiểm thử.

Ví dụ: Một team chưa có kỹ năng automation không thể ngay lập tức đặt mục tiêu tự động hóa toàn bộ regression suite. Phải cần lộ trình và thời gian

3. Business domain

Độ critical của test object, product risks, nhu cầu thị trường và quy định pháp lý quyết định mức độ nghiêm ngặt của testing.

Ví dụ: Phần mềm y tế, tài chính thường cần coverage, traceability và bằng chứng kiểm thử cao hơn một website giới thiệu nội bộ.

4. Technical factors

Loại phần mềm, kiến trúc sản phẩm và công nghệ được sử dụng ảnh hưởng đến test levels, test techniques, môi trường và công cụ.

Ví dụ: Một hệ thống microservices cần chú trọng API, contract và system integration testing; ứng dụng desktop lại cần quan tâm đến hệ điều hành, thiết bị và tương tác giao diện.

5. Project constraints

Scope, thời gian, ngân sách và nguồn lực luôn tạo ra giới hạn. Khi deadline ngắn, team không nên bỏ testing một cách tùy tiện mà cần ưu tiên theo risk, tập trung vào luồng nghiệp vụ quan trọng và chọn mức coverage khả thi.

6. Organizational factors

Cơ cấu tổ chức, policy và practice hiện có ảnh hưởng đến test roles, mức độ độc lập, approval flow và tài liệu bắt buộc.

Ví dụ: Một công ty nhỏ có thể dùng Whole Team Approach, trong khi tổ chức lớn có thể có test team độc lập và quality gate riêng.

7. Software Development Lifecycle

Engineering practices và development method quyết định thời điểm cũng như nhịp độ testing. Waterfall thường có các giai đoạn và tài liệu rõ ràng; Agile cần feedback liên tục trong Sprint

8. Tools

Availability, usability và compliance của công cụ ảnh hưởng đến khả năng quản lý testware, thực thi automation, theo dõi defect và tạo báo cáo. Công cụ phù hợp có thể tăng hiệu quả, nhưng không nên chọn test process chỉ để phục vụ một công cụ đang có.

Ví dụ: cùng một sản phẩm, khác bối cảnh

Giả sử hai team cùng phát triển chức năng đăng ký tài khoản:

Startup thử nghiệm MVP	Nền tảng tài chính đã vận hành
Deadline ngắn, ít người dùng	Dữ liệu nhạy cảm, nhiều người dùng
Ưu tiên happy path và rủi ro lớn nhất	Coverage rộng gồm security, privacy và audit
Checklist gọn, báo cáo trực tiếp trong team	Test case, traceability và evidence chi tiết
Automation chọn lọc cho luồng ổn định	Regression automation trong CI/CD

Không thể kết luận quy trình thứ nhất thiếu chuyên nghiệp hoặc quy trình thứ hai quá nặng nề nếu chưa xét bối cảnh. Câu hỏi đúng phải là: cách tổ chức testing này có kiểm soát được rủi ro và đáp ứng nhu cầu stakeholder hay không?

Kết luận

Test Process in Context nhắc chúng ta rằng test process không phải một template bất biến. Quy trình hiệu quả phải được thiết kế và liên tục điều chỉnh dựa trên stakeholder, con người, domain, công nghệ, constraint, tổ chức, SDLC và công cụ.