Kiểm thử hồi quy theo rủi ro: kiểm gì khi không đủ thời gian
Regression không phải “chạy lại tất cả”. Trong release thật, thời gian luôn thiếu, nên kỹ năng quan trọng là chọn phần cần kiểm trước.
- Đọc phần đã thay đổi
- Tìm flow bị ảnh hưởng
- Chọn check có impact cao
- Nói rõ phần chưa kiểm
Bắt đầu từ thay đổi
Đừng bắt đầu từ thói quen. Hãy đọc release notes, ticket hoặc hỏi developer: thay đổi gì và có thể chạm tới đâu.
Cùng một lỗi checkout quan trọng hơn nhiều sau refactor payment.
Rủi ro cao là gì
Rủi ro cao là impact lớn hoặc khả năng xảy ra cao: tiền, login, quyền, dữ liệu cá nhân, đơn hàng, payment và integration.
- Flow chặn công việc chính của user.
- Flow liên quan tiền hoặc dữ liệu không thể hoàn tác.
- Vùng bị release chạm tới.
- Vùng có nhiều bug gần đây.
- Integration khó thấy lỗi trên UI.
Nói “chưa kiểm” thế nào cho an toàn
QA không âm thầm bỏ qua. Hãy nói phần nào chưa kiểm và vì sao.
“Chưa test” không xấu nếu nó rõ ràng. Nó nguy hiểm khi mọi người tưởng đã có ai đó kiểm.
Checklist regression ngắn
Smoke flow, phần vừa đổi, phần gần đó, quyền truy cập, case âm quan trọng và một end-to-end business path.
Với API, thêm schema compatibility, error handling, idempotency và client cũ.
Sau release cải thiện gì
Mỗi bug lọt ra ngoài cho biết regression thiếu tín hiệu nào: test case, data, owner, log hay automation guard.
Regression tốt hơn khi được biên tập, không chỉ phình to.
Matrix xác suất × impact
Dùng thang 1–3. Xác suất tăng ở vùng vừa đổi, phức tạp, từng lỗi hoặc dependency không ổn định. Impact tăng với mất tiền/data, security, chặn core journey và nhiều user. Score giúp so sánh nhưng không thay discussion: 3×3 đi trước 1×3.
Thêm confidence. Integration team chưa hiểu rõ có thể được nâng ưu tiên dù chưa có lịch sử bug. Ghi lý do cho mỗi score, nếu không matrix chỉ là trang trí.
Scenario P I Score Quyết định\nPayment callback lặp 3 3 9 kiểm trước\nMobile client cũ 2 3 6 contract + smoke\nFilter lịch sử order 2 1 2 lấy mẫu\nText footer 1 1 1 ngoài scope
Ví dụ: 90 phút regression payment
Dành 10 phút đọc diff, ticket và rollout plan; 15 phút smoke login, catalogue, checkout; 40 phút cho success, decline, timeout/retry, callback lặp, idempotency key và đối soát; 15 phút cho client cũ và permission; 10 phút xem log, metric và viết summary.
Currency hiếm và full promotion chưa được cover. Hãy ghi vì sao chúng thấp hơn, ai nhận risk và monitoring nào phát hiện vấn đề khi rollout.
Test summary đủ để quyết định release
Ghi build và environment, scope, kết quả critical, defect mở, vùng chưa kiểm, metric và recommendation của QA. QA không tự “cho phép” release; team hoặc risk owner quyết định.
Ví dụ: “Critical payment flow pass trên build 1842. Còn blocker PAY-91: callback lặp charge hai lần. Đề nghị dừng rollout. Chưa kiểm JPY và Android 11; release owner nhận risk nếu tiếp tục.”
Ví dụ thực tế: release đổi cách làm tròn phí
Service tính phí vừa thay đổi. Chỉ còn 90 phút trước release, trong khi cả suite chạy hai ngày. QA phải chọn kiểm tra theo vùng ảnh hưởng và nêu rủi ro còn lại, không giả vờ mọi thứ đã được kiểm.
- Xác định rule thay đổi và consumer.
- Xếp hạng theo xác suất và tác động.
- Kiểm luồng quan trọng và phần liên quan.
- Công bố kết quả và rủi ro còn lại.
Lập bản đồ ảnh hưởng trước khi test
Đọc diff, ticket và lịch sử incident. Kết quả tính phí có thể dùng trong chuyển tiền, hoàn tiền, hủy, sao kê và thông báo. Đánh dấu currency, đơn vị lưu, thứ tự làm tròn và hành vi client cũ. Dù diff chỉ đổi công thức, vẫn hỏi thành phần nào cache kết quả hoặc retry sau timeout.
Giảm scope có chủ đích
Bắt đầu với sign-in, truy cập account và chuyển tiền cơ bản. Tiếp theo kiểm biên làm tròn, đơn vị tiền nhỏ nhất, đúng số dư còn lại, thiếu tiền, retry cùng key, refund và statement. Chia case thành bắt buộc trước release và có thể kiểm khi rollout. Ưu tiên nguy cơ mất tiền hay sai balance, không chỉ test chạy nhanh.
Dùng oracle độc lập
Tính phí mong đợi độc lập với API response theo công thức đã chốt và bộ giá trị chuẩn bị trước. Số 1.005 có thể cho kết quả khác tùy rule làm tròn; test không có rule rõ ràng sẽ vô nghĩa. So response, balance của hai account, transaction record và statement. Hai màn hình xanh chưa chứng minh ledger bên trong nhất quán.
Viết báo cáo đủ để quyết định
Nêu build, environment, kết quả critical, defect còn mở và vùng chưa kiểm. Không che Android cũ hay tiền tệ hiếm bằng câu “regression passed”. Nêu người quyết định release, tín hiệu giám sát và ngưỡng rollback. Nếu thấy trừ tiền hai lần, khuyến nghị dừng rollout dù tỷ lệ test pass cao.
Build 1842 / QA / payment-fee rollout\nPassed: transfer, insufficient funds, boundary, retry, refund\nBlocked: none\nNot checked: Android 11, JPY rounding, delayed export\nResidual risk: old client may parse fee field differently\nMonitor: duplicate charges, ledger mismatch, 5xx, fee delta\nRecommendation: staged rollout with agreed rollback threshold
Vì sao đây là regression theo rủi ro?
Tập kiểm tra đi theo thay đổi, consumer và hậu quả có thể xảy ra thay vì thứ tự checklist cũ. Nó không hứa an toàn tuyệt đối nhưng cho team thấy điều gì đã kiểm, khoảng trống nào còn lại và cần theo dõi gì sau deploy.
Tình huống thứ hai: thay đổi khi chuyển đổi lead trong CRM
Thay đổi nhỏ tạo task cho manager khi lead được chuyển đổi. Hành động này còn chạm customer, deal, owner, notification và retry. Regression cần theo trạng thái liên quan; nút Convert báo thành công vẫn có thể che dữ liệu sai.
Vẽ sơ đồ phụ thuộc
Liệt kê lead, customer, deal, activity, task và notification. Đánh dấu object nào được tạo hay cập nhật và khóa liên kết. Xác định thao tác nào đồng bộ, thao tác nào đi qua queue. Với task đến trễ, chờ trạng thái quan sát được trong timeout giới hạn thay vì sleep cố định năm giây. Kiểm owner của task có quyền thấy customer mới.
Chọn các trường hợp kiểm soát
Tối thiểu: chuyển đổi lần đầu, lặp lại, email customer đã có và thiếu field bắt buộc. Thêm manager khác và lỗi khi tạo task. Nếu customer đã tạo nhưng task lỗi, expected phụ thuộc contract: rollback toàn bộ hay retry. Làm rõ trước khi báo trạng thái một phần là defect.
Đếm object và đối chiếu id
Sau chuyển đổi, mong đợi đúng một customer, deal và task ở trạng thái thích hợp. Gửi request lần nữa rồi so id và số lượng: thông báo “already converted” không chứng minh không có bản sao. Kiểm task.customer_id, deal.customer_id và owner_id. Unique validation trên UI không bảo vệ hai request API đồng thời, nên kiểm race riêng.
Kiểm hạn task và reminder
Task quá hạn không được biến thành task thường do chuyển timezone. Dùng ngày cố định trong môi trường test; so due_at trong API, màn hình manager và thứ tự overdue. Làm rõ quy tắc DST và ngày địa phương. Message được gửi lại không được tạo notification trùng.
Công khai phần chưa kiểm trước release
Nếu chưa kịp kiểm nhiều tenant và lead cũ sau migration, ghi rõ. Chuyển đổi lặp và quyền xem customer mới là critical vì ảnh hưởng dữ liệu và access. Sau rollout theo dõi chuyển đổi thất bại, customer trùng và độ dài task queue. Báo cáo này hữu ích hơn “CRM regression passed”.
Case Client Deal Task Lead state\nfirst convert +1 +1 +1 converted\nrepeat same lead +0 +0 +0 converted\ninvalid lead +0 +0 +0 unchanged\ntask worker fails contract-defined retry or rollback\nsecond manager no access unless assigned
Vì sao đây là regression?
Nó kiểm invariant giữa các object, role, event bất đồng bộ và lời gọi lặp thay vì chỉ một nút. Ma trận giúp kỹ thuật và release owner hiểu rủi ro, đồng thời có thể mở rộng theo quy trình bán hàng.
Câu hỏi thường gặp về regression
Smoke khác regression thế nào?
Smoke trả lời nhanh build có test được và core function có chạy không. Regression tìm side effect của thay đổi trong behaviour cũ. Smoke thường là một phần, không thay thế regression.
Luôn phải chạy toàn bộ automated suite không?
Thường có nếu suite nhanh, ổn định và rẻ, nhưng kết quả xanh không thay impact analysis, exploratory cho risk mới hay việc sửa test chậm và flaky.
Ai nhận residual risk?
Không phải QA một mình. QA làm evidence và gap rõ ràng; product, engineering hoặc release owner quyết định theo process của team.
Regression tốt là ưu tiên hoá rõ ràng: bảo vệ sản phẩm và cho team thấy rủi ro nào vẫn được ship.