Kiểm thử hồi quy chọn lọc & ưu tiên ca cho Tester: chọn tập tối ưu khi hết thời gian (có trắc nghiệm)

1. Tóm tắt nhanh & màn hình bạn sẽ test

Khi đội test đã có hàng nghìn ca hồi quy tích luỹ qua nhiều sprint, chạy lại TOÀN BỘ trước mỗi lần release gần như không khả thi — nhất là với SaaS release liên tục (continuous delivery). Bài toán thực tế không phải 'test hết' mà là 'test ĐÚNG những gì có nguy cơ vỡ nhất, trong thời gian có hạn'. Đây chính là kỹ năng kiểm thử hồi quy chọn lọc & ưu tiên ca — một trong những kỹ năng phân biệt tester cấp senior với tester chỉ biết chạy theo checklist có sẵn.

2. Retest-all, chọn lọc và ưu tiên ca — ba chiến lược khác nhau

Có ba chiến lược hồi quy thường gặp, và tester nâng cao cần phân biệt rạch ròi. Retest-all chạy lại toàn bộ ca — an toàn nhất nhưng tốn thời gian nhất, chỉ hợp khi hệ thống nhỏ hoặc có đủ tài nguyên CI để chạy song song không giới hạn. Kiểm thử hồi quy chọn lọc (selective) loại bỏ hẳn những ca được xác định là KHÔNG bị ảnh hưởng bởi thay đổi, dựa trên bằng chứng kỹ thuật (dependency graph, code coverage diff) chứ không phải cảm tính. Ưu tiên ca (prioritization) thì khác: vẫn giữ toàn bộ ca trong danh sách, nhưng sắp xếp lại thứ tự chạy để những ca giá trị cao nhất được thực hiện sớm nhất trong ngân sách thời gian có hạn.

Ba chiến lược này không loại trừ nhau — thực tế đội ngũ trưởng thành thường kết hợp cả ba: chọn lọc trước để loại các module chắc chắn không liên quan, sau đó ưu tiên phần còn lại theo điểm rủi ro, và cuối cùng vẫn giữ một lớp retest-all chạy định kỳ (đêm/cuối tuần) làm lưới an toàn cuối cùng. Bạn sẽ thấy mô hình kết hợp này ở chương 8 khi ta xây bộ hồi quy phân tầng cho ProjectFlow.

3. Vì sao chọn lọc & ưu tiên đặc biệt quan trọng ở SaaS đa tenant

ProjectFlow là một SaaS quản lý dự án phục vụ hàng trăm tổ chức (tenant) trên CÙNG một hạ tầng dùng chung. Đặc điểm này tạo ra hai áp lực trái chiều: một mặt, release phải diễn ra liên tục (nhiều lần/tuần) để đưa tính năng tới khách hàng nhanh; mặt khác, một lỗi ở module dùng chung (như billing-core hay hệ thống xác thực SSO) có thể ảnh hưởng ĐỒNG THỜI hàng trăm tenant thay vì một khách hàng đơn lẻ như phần mềm cài đặt riêng lẻ (on-premise).

Chính vì vậy, chạy retest-all mỗi lần release vừa không kịp tốc độ continuous delivery, vừa lãng phí — vì phần lớn thay đổi mỗi sprint chỉ chạm tới một module hẹp. Nhưng bỏ qua kiểm thử hồi quy hoàn toàn lại quá rủi ro, vì một thay đổi tưởng nhỏ ở module dùng chung có thể gây thiệt hại trên diện rộng chỉ trong vài giờ, trước khi ai kịp phát hiện. Kiểm thử hồi quy chọn lọc & ưu tiên ca chính là câu trả lời cân bằng giữa hai áp lực đó — vừa nhanh, vừa đủ an toàn cho một hệ thống đa tenant.

Một điểm riêng của SaaS đa tenant là 'blast radius' (bán kính ảnh hưởng) khác hẳn phần mềm đơn lẻ: cùng một dòng code lỗi, on-premise chỉ ảnh hưởng một khách, còn SaaS đa tenant có thể ảnh hưởng toàn bộ khách hàng cùng lúc. Vì vậy khi chấm điểm rủi ro ở chương 5, ta luôn cộng thêm trọng số cho các module dùng chung (shared/core) — chúng luôn xứng đáng nằm trong tập chọn lọc dù thay đổi trông có vẻ nhỏ.

4. Chuẩn bị: ba chiến lược chọn tập hồi quy

Trước khi chọn ca, bạn cần một QUY TRÌNH lặp lại được, không phải cảm tính mỗi lần một kiểu. Có ba nguồn dữ liệu chính để dựng tập chọn lọc, và một tester nâng cao nên phối hợp cả ba thay vì chỉ dùng một.

▶ Bước 1: Vùng ảnh hưởng thay đổi (change impact analysis): đọc git diff của release, dựng dependency graph (module nào import/gọi module nào) để biết thay đổi lan tới đâu ngoài file bị sửa trực tiếp.

▶ Bước 2: Rủi ro nghiệp vụ (risk-based): với mỗi module bị ảnh hưởng, hỏi 'nếu tính năng này hỏng, thiệt hại là gì — mất tiền, mất dữ liệu, vi phạm hợp đồng SLA?' rồi chấm điểm rủi ro tương ứng.

▶ Bước 3: Lịch sử lỗi (defect history): tra cứu số lỗi Critical/High của mỗi module trong 6–12 tháng gần nhất trong hệ thống theo dõi lỗi (Jira) — module hay lỗi có xu hướng TIẾP TỤC sinh lỗi theo nguyên lý cụm lỗi (defect clustering, dạng Pareto 80/20).