Kiểm thử ERP là kiểm tra phần mềm quản lý doanh nghiệp có xử lý đúng công việc, số liệu và quyền truy cập hay không. UAT (kiểm thử chấp nhận của người dùng) là khi nhân viên bán hàng, kho, kế toán hoặc bộ phận liên quan trực tiếp thử việc họ sẽ làm hằng ngày, ghi kết quả và xác nhận ERP có đáp ứng yêu cầu trước khi đưa vào vận hành.
UAT không phải buổi nhà cung cấp trình diễn chức năng. Người dùng cần kiểm tra cả tình huống bình thường lẫn trường hợp sai hoặc thiếu thông tin. Bài này hướng dẫn 8 bước, mẫu kiểm thử dễ điền và cách xử lý lỗi trước khi nghiệm thu; để xem tổng thể dự án, đọc quy trình triển khai ERP.
Có những loại kiểm thử ERP nào?
| Loại kiểm tra | Ai hoặc bộ phận thường tham gia? | Cần xác nhận |
|---|---|---|
| Chức năng | Nhân viên nghiệp vụ, tư vấn triển khai | Một thao tác làm đúng yêu cầu. |
| Kết nối hệ thống | Kỹ thuật và người sử dụng | Đơn, kho, hóa đơn gửi nhận đúng. |
| Quy trình đầu đến cuối | Bán hàng, kho, kế toán | Tạo đơn → xuất kho → lập hóa đơn. |
| Dữ liệu chuyển đổi | Thủ kho, kế toán, người quản lý dữ liệu | Tồn kho, số dư và công nợ khớp. |
| Quyền truy cập | Người quản lý và kỹ thuật | Đúng người được xem, sửa, duyệt. |
| Hiệu năng | Kỹ thuật cùng người sử dụng | Tốc độ đáp ứng khi tải thực tế. |
| Kiểm thử lại sau sửa | Người kiểm thử và kỹ thuật | Sửa lỗi không làm hỏng việc khác. |
| UAT – nghiệm thu người dùng | Đại diện các bộ phận | Công việc thực tế đạt điều kiện chấp nhận. |
UAT khác demo, đào tạo và diễn tập Go-live ra sao?
Demo: nhà cung cấp giới thiệu phần mềm. Đào tạo: nhân viên học cách thao tác. UAT: nhân viên tự thử và ghi đạt hoặc không đạt. Diễn tập Go-live: chạy thử kế hoạch đưa hệ thống mới vào sử dụng, gồm chuyển dữ liệu và phối hợp các nhóm. Các công việc này có liên quan nhưng không thay thế nhau.
Bước 1. Chọn những công việc quan trọng phải thử
Ưu tiên việc có thể làm gián đoạn bán hàng, xuất kho, kế toán, thanh toán hoặc ảnh hưởng dữ liệu. Ví dụ: tạo đơn, phê duyệt giảm giá, chuyển hàng giữa kho, thu tiền và đối chiếu công nợ. Đừng dành nhiều thời gian thử màu giao diện trong khi các công việc này chưa chạy đúng.
Lập danh sách từng tình huống, bộ phận chịu trách nhiệm và người trực tiếp thử. Phạm vi kiểm thử cần bám hợp đồng, yêu cầu nghiệp vụ và mức rủi ro, không bắt mọi dự án làm y hệt nhau.
Bước 2. Viết test case: có thao tác và kết quả mong đợi
Test case là một tình huống kiểm tra có hướng dẫn thao tác và kết quả phải đạt. Mỗi tình huống nên ghi mã, người kiểm tra, điều kiện ban đầu, thao tác, kết quả mong đợi, kết quả thực tế và bằng chứng. Đây là mẫu giả định để người đọc điều chỉnh, không phải kết quả dự án khách hàng có thật.
| Thông tin | Ví dụ kiểm thử điều chuyển kho |
|---|---|
| Mã và người thử | KHO-01 – Đại diện bộ phận kho. |
| Điều kiện | Kho A có hàng; nhân viên kho không có quyền tự phê duyệt. |
| Thao tác | Tạo yêu cầu chuyển 5 sản phẩm từ kho A sang kho B; trưởng kho duyệt. |
| Kết quả mong đợi | Chỉ hoàn tất khi được duyệt; tồn kho A giảm 5, kho B tăng 5. |
| Kết quả thực tế | Người thử ghi sau khi thực hiện; không điền trước là “Đạt”. |
| Kết luận và bằng chứng | Đạt / Không đạt / Chưa thử; ảnh phiếu, mã giao dịch, mã lỗi nếu có. |
Kết quả mong đợi phải cụ thể. “Không thấy báo lỗi” chưa đủ: cần xác nhận chứng từ, tồn kho và quyền phê duyệt thực sự đúng. SAP khuyến nghị gắn tình huống thử với vai trò từng nhân viên và ghi nhận kết quả của chính người thực hiện.
Bước 3. Kiểm tra số liệu được chuyển sang ERP
Bên kỹ thuật có thể báo “nhập dữ liệu thành công”, nhưng thủ kho và kế toán vẫn phải kiểm tra số lượng tồn, số dư, công nợ và giao dịch đang xử lý. Dữ liệu không chỉ cần đủ số dòng mà còn đúng số tiền, đúng mã hàng và đúng khách hàng.
Ghi chênh lệch, người xử lý và kết quả đối chiếu trước khi chấp thuận. Quy trình chuyển đổi chuyên sâu nằm tại hướng dẫn chuyển dữ liệu ERP.
Bước 4. Thử cả khi các phần mềm kết nối gặp lỗi
Đừng chỉ thử trường hợp mọi thứ hoạt động bình thường. Nếu website gửi đơn hàng sang ERP, hãy thử tình huống kết nối bị gián đoạn, gửi lại hoặc dữ liệu thiếu. Kiểm tra xem có đơn trùng, đơn mất hoặc sai trạng thái không; ai nhận thông báo và sửa sai lệch.
Một phản hồi kỹ thuật “kết nối thành công” không có nghĩa đơn hàng đã được ghi nhận đúng trong ERP. Tham khảo hướng dẫn tích hợp ERP nếu dự án liên quan nhiều ứng dụng.
Bước 5. Kiểm tra đúng người được phép thao tác
Hãy cho nhân viên dùng đúng tài khoản và vai trò của mình. Ví dụ, nhân viên bán hàng được tạo đơn nhưng không thể tự duyệt giảm giá vượt quyền; trưởng bộ phận phải duyệt được đúng yêu cầu. Cần thử cả việc được phép và việc phải bị từ chối.
Chỉ thử đăng nhập thành công không đủ kiểm tra bảo mật. Với nghiệp vụ nhạy cảm, cũng nên kiểm tra dấu vết người đã sửa hoặc duyệt chứng từ.
Bước 6. Ghi lỗi và ưu tiên theo ảnh hưởng kinh doanh
Khi kiểm thử thất bại, ghi lại tình huống, bước xảy ra lỗi, ảnh chụp hoặc mã giao dịch, mức ảnh hưởng và người phụ trách sửa. Lỗi chặn là lỗi khiến công việc quan trọng không thể tiếp tục an toàn; lỗi cao gây ảnh hưởng lớn; lỗi nhẹ ít ảnh hưởng hơn và có thể có cách xử lý tạm được duyệt.
Không nên hạ mức độ lỗi chỉ vì đã gần ngày mở hệ thống. Mức ưu tiên và trường hợp được nghiệm thu có điều kiện cần do doanh nghiệp thống nhất với đối tác trước khi thử.
Bước 7. Sau khi sửa phải kiểm thử lại
Nhà cung cấp sửa một lỗi chưa có nghĩa toàn bộ quy trình đã ổn. Người đã phát hiện lỗi cần thử lại tình huống đó, sau đó kiểm tra các chức năng liên quan; đây gọi là kiểm thử hồi quy (regression). Ví dụ, sửa tính giá bán thì phải thử lại đơn, chiết khấu và hóa đơn liên quan.
Đối với thay đổi lớn hoặc nâng cấp phiên bản, cần thử lại các luồng nghiệp vụ quan trọng. Tham khảo thêm cách kiểm tra khi nâng cấp ERP.
Bước 8. Nghiệm thu UAT dựa trên bằng chứng
Ký nghiệm thu UAT (sign-off) nghĩa là người phụ trách nghiệp vụ đã xem kết quả thử, hiểu những lỗi còn tồn và chấp thuận mức rủi ro theo thỏa thuận. Không nhất thiết mọi lỗi nhỏ đều phải bằng 0, nhưng lỗi nghiêm trọng có thể làm gián đoạn nghiệp vụ hoặc sai dữ liệu thì không nên bỏ qua.
Biên bản cần nêu phiên bản ERP được thử, danh sách tình huống đã hoàn thành, lỗi còn mở, phương án xử lý, người chịu trách nhiệm và quyết định đạt, đạt có điều kiện hoặc chưa đạt. Ký UAT không thay cho quyết định Go/No-Go; việc chuyển hệ thống vẫn phải qua kế hoạch riêng.
Có nên dùng dữ liệu thật để UAT không?
Không nhất thiết. Nên dùng môi trường kiểm thử tách khỏi hệ thống đang phục vụ khách hàng, cùng dữ liệu đại diện đủ để thử nghiệp vụ. Nếu cần dữ liệu gần giống thực tế, hãy che thông tin nhạy cảm hoặc tạo dữ liệu giả phù hợp; quyền sử dụng dữ liệu phải được kiểm soát. Oracle NetSuite cũng khuyến nghị UAT trong môi trường an toàn, tách biệt.
Checklist trước khi ký nghiệm thu kiểm thử ERP
- Đã chọn công việc quan trọng và có người chịu trách nhiệm từng tình huống.
- Mỗi tình huống có thao tác, kết quả mong đợi, kết quả thực tế và bằng chứng.
- Đã kiểm tra dữ liệu chuyển đổi và các phần mềm kết nối cần thiết.
- Đã thử phân quyền và những trường hợp nhân viên không được thực hiện.
- Đã xem khả năng đáp ứng khi nhiều người làm việc, nếu dự án cần.
- Các lỗi chặn đã được xử lý hoặc có quyết định không nghiệm thu; lỗi khác có người phụ trách và kế hoạch.
- Sau sửa lỗi quan trọng đã thử lại chức năng liên quan.
- Đại diện bộ phận sử dụng xem hồ sơ và xác nhận kết quả UAT.
Sau nghiệm thu UAT, doanh nghiệp tiếp tục rà soát checklist Go-live ERP trước khi quyết định chạy chính thức. Đây là hai cột mốc khác nhau.
Nguồn kiểm chứng và nội dung nên đọc tiếp
Tài liệu kiểm chứng: Microsoft – Chiến lược kiểm thử ERP; SAP – Lập test case và phân người kiểm thử UAT; Oracle NetSuite – UAT trong môi trường kiểm thử. Các nguồn hướng dẫn cho sản phẩm cụ thể, không phải tỷ lệ nghiệm thu hoặc quy định bắt buộc chung cho mọi ERP. Đối chiếu ngày 24/10/2026.
Để nhân viên sẵn sàng sử dụng phần mềm và hạn chế quyền quá rộng, tham khảo quản lý thay đổi ERP và bảo mật, phân quyền ERP. Cần kiểm tra thêm khả năng sao lưu, phục hồi và chỉ số theo dõi sau triển khai.
Nếu kiểm thử thuộc dự án Odoo, hãy thống nhất test case, người tham gia, điều kiện nghiệm thu và việc sửa lỗi trong phạm vi triển khai Odoo.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.