<< Quay lại Tin tức & chia sẻ

Quy trình test automation và rollback 

26/02/2026 | David Phước | Tự động hóa

Quy trình test automation và rollback: cách chạy thử, đo lỗi và quay lại phương án cũ khi cần  

Automation không phải “làm xong là chạy mãi”. Nếu không có quy trình test và rollback, bạn rất dễ rơi vào cảnh hệ thống chạy sai, lỗi lan rộng, đội nhóm mất niềm tin và cuối cùng quay về làm thủ công trong hỗn loạn. Một quy trình test tốt giúp bạn triển khai an toàn theo kiểu “nhỏ nhưng chắc”: chạy thử trong phạm vi hẹp, đo lỗi rõ ràng, và luôn có đường quay về phương án cũ khi có sự cố. 

Bài này hướng dẫn cách test automation theo từng bước và thiết kế rollback đơn giản cho SME. 

1) Vì sao automation cần test và rollback như một “luật bắt buộc”?

Automation làm tăng tốc độ xử lý, nhưng cũng làm tăng tốc độ lan lỗi. Chỉ cần một rule sai, một trường dữ liệu đổi tên, hoặc một điều kiện ngoại lệ bị bỏ qua, bạn có thể tạo ra hàng loạt sai sót trong vài giờ. 

Vì vậy test và rollback giống như “phanh” và “dây an toàn”: test để phát hiện lỗi trước khi triển khai rộng, rollback để hạn chế thiệt hại khi lỗi vẫn xảy ra. Nếu bạn muốn đội nhóm tin tưởng automation, bạn cần cho họ thấy hệ thống có kiểm soát, có đo lường và có phương án quay về an toàn.

2) Chuẩn bị trước khi test: baseline, dữ liệu mẫu và tiêu chí pass/ fail

Trước khi chạy thử, bạn cần một baseline để so sánh, nếu không bạn sẽ không biết automation có giúp hay chỉ tạo thêm rối. Baseline tối thiểu có thể là thời gian xử lý trung bình, số lỗi/ lần làm lại, tỷ lệ trễ SLA hoặc số bước thao tác thủ công trong một ngày. 

Tiếp theo, bạn cần bộ dữ liệu mẫu đại diện, gồm cả case “đẹp” và case “xấu” (thiếu thông tin, ngoại lệ, lỗi thường gặp), vì automation thường chỉ chạy tốt với case đẹp nếu bạn không test ngoại lệ. 

Cuối cùng, bạn phải định nghĩa tiêu chí pass/ fail rõ ràng, ví dụ tỷ lệ lỗi cho phép, thời gian xử lý giảm bao nhiêu, hoặc trường hợp nào bắt buộc phải chuyển sang human-in-the-loop; đây là phần quyết định việc bạn dừng hay mở rộng sau pilot.

3) Quy trình test automation theo 7 bước

• • • Bước đầu tiên là khoanh phạm vi pilot thật hẹp, như một team nhỏ, một ca làm hoặc một loại case cụ thể, để nếu có lỗi thì ảnh hưởng không lan rộng. 

    • Bước thứ hai là chạy thử “dry run”, nghĩa là automation chạy nhưng không thực thi hành động cuối cùng (không gửi ra ngoài hoặc không cập nhật trạng thái quan trọng), chỉ tạo nháp và log; bước này giúp bạn kiểm tra logic mà không gây thiệt hại. 

    • Bước thứ ba là test theo kịch bản, tức là bạn đưa lần lượt các case mẫu vào và kiểm tra đầu ra so với kỳ vọng, đặc biệt chú ý các case ngoại lệ. 

    • Bước thứ tư là bật chế độ “limited live”, nghĩa là cho automation thực thi thật nhưng chỉ với những case rủi ro thấp hoặc với điều kiện luôn có người duyệt ở điểm chặn; đây là lúc bạn kiểm tra hệ thống trong môi trường thật. 

    • Bước thứ năm là ghi log và phân loại lỗi theo nhóm như lỗi dữ liệu đầu vào, lỗi rule/logic, lỗi tích hợp công cụ, và lỗi do ngoại lệ chưa được thiết kế; phân loại đúng giúp bạn sửa nhanh và không lặp lại. 

    • Bước thứ sáu là tinh chỉnh theo vòng lặp ngắn, mỗi lần sửa chỉ thay đổi một vài điểm, rồi test lại bằng bộ case mẫu để chắc chắn không “sửa chỗ này hỏng chỗ kia”. 

    • Bước cuối cùng là đánh giá cuối pilot bằng số liệu trước - sau, chốt quyết định mở rộng, giữ nguyên hoặc rollback, đồng thời cập nhật SOP/ hướng dẫn vận hành automation để đội nhóm biết cách dùng và xử lý khi có lỗi.

4) Bộ chỉ số đo lỗi và hiệu quả trong giai đoạn pilot

Trong pilot, bạn cần đo cả hiệu quả lẫn rủi ro. Về hiệu quả, bạn có thể đo thời gian xử lý trung bình, số thao tác thủ công giảm được, hoặc tốc độ phản hồi cải thiện như thế nào. Về chất lượng, bạn đo tỷ lệ lỗi của automation, số case bị làm sai phải sửa lại, và tỷ lệ case phải chuyển sang người duyệt. 

Về vận hành hệ thống, bạn đo thời gian bạn phải bỏ ra để sửa rule, xử lý sự cố và hỗ trợ người dùng; nhiều nơi bỏ qua phần này nên ROI bị “ảo”. 

Ngoài ra, bạn nên đo độ ổn định: số lần automation bị fail, số lần tích hợp lỗi, hoặc số lần dữ liệu đầu vào không đúng format khiến quy trình dừng.

5) Thiết kế rollback: khi nào rollback, rollback cái gì, rollback như thế nào

Rollback không nên là quyết định cảm tính, mà nên có “ngưỡng kích hoạt” rõ ràng. Bạn nên rollback ngay khi lỗi có nguy cơ lan rộng, khi sai sót ảnh hưởng khách hàng/ tiền/ uy tín, khi tỷ lệ lỗi vượt ngưỡng pass/fail, hoặc khi đội nhóm không thể vận hành vì hệ thống gây kẹt. 

Về rollback cái gì, bạn cần xác định các điểm có thể quay về thủ công, ví dụ tắt bước tự động gửi ra ngoài, tắt bước cập nhật trạng thái quan trọng, hoặc chuyển toàn bộ case về hàng xử lý thủ công với checklist tạm thời. Về rollback như thế nào, cách an toàn nhất là thiết kế automation theo module và có công tắc bật/ tắt theo từng phần, đồng thời có log để biết automation đã tác động lên case nào để bạn sửa lại dữ liệu nếu cần. 

Sau rollback, bạn cần một quy trình “khôi phục” gồm rà các case bị ảnh hưởng, sửa dữ liệu sai, cập nhật rule/prompt, test lại bằng bộ case mẫu, rồi mới bật lại theo chế độ limited live.

6) Lỗi thường gặp và cách tránh

• • • Lỗi phổ biến nhất là test quá ít case và bỏ qua ngoại lệ, khiến hệ thống chạy tốt vài ngày rồi gặp tình huống thật thì vỡ; cách tránh là luôn có bộ case mẫu gồm cả case xấu. 

    • Lỗi thứ hai là không có baseline và tiêu chí pass/fail, nên không biết kết quả pilot tốt hay xấu; hãy chốt chỉ số trước khi bắt đầu. 

    • Lỗi thứ ba là triển khai rộng quá nhanh, không khoanh phạm vi; hãy pilot hẹp và mở rộng theo từng lớp. 

    • Lỗi thứ tư là không ghi log hoặc không phân loại lỗi, dẫn đến sửa lâu và lặp lại; hãy bắt buộc log và phân nhóm lỗi. 

    • Lỗi cuối cùng là không thiết kế rollback ngay từ đầu; hãy coi rollback là một phần của thiết kế, không phải phương án chữa cháy.

7) FAQ

Pilot bao lâu là đủ?
Thường 7 - 14 ngày đủ để thấy xu hướng, phát hiện lỗi hệ thống và đánh giá ROI sơ bộ.

Có cần test “dry run” không?
Rất nên, vì dry run giúp bạn kiểm logic mà không gây tác động thật ra bên ngoài.

Rollback có làm mất uy tín automation không?
Ngược lại, rollback đúng lúc giúp đội nhóm tin rằng hệ thống có kiểm soát và ưu tiên an toàn.

Sau rollback, khi nào bật lại?
Khi bạn đã sửa lỗi gốc, test lại bằng bộ case mẫu, và bật lại theo chế độ limited live với điểm chặn kiểm duyệt.