Kiểm thử ERP và UAT không phải một buổi demo trước go-live. Testing cần chứng minh hệ thống, integration, dữ liệu, quyền truy cập và critical business flow hoạt động theo expected result; UAT cần chứng minh người dùng nghiệp vụ chấp nhận rằng hệ thống hỗ trợ công việc thật theo điều kiện đã thống nhất.
Một dự án ERP có thể có nhiều lớp test: functional, integration, end-to-end, security/permission, migration validation, regression, performance và UAT. Không phải dự án nào cũng cần cùng độ sâu, nhưng critical process phải có evidence trước khi đi tới go/no-go. Xem quy trình triển khai ERP để đặt testing đúng phase.
Các lớp kiểm thử ERP cần phân biệt
| Lớp test | Mục tiêu | Ví dụ |
|---|---|---|
| Functional | Một chức năng/rule riêng lẻ đúng | Approval theo threshold |
| Integration | Dữ liệu đi qua nhiều hệ thống đúng | CRM → ERP order handoff |
| End-to-End | Business flow từ đầu đến cuối đúng | Order → Ship → Invoice → Payment |
| Security/Permission | Đúng người có đúng quyền | User không được post journal ngoài role |
| Migration Validation | Dữ liệu sau load đúng | Inventory/AR/AP/GL reconcile |
| Regression | Thay đổi mới không phá flow cũ | Custom mới không làm hỏng return process |
| UAT | Business user chấp nhận critical scenario | Key user tự chạy order exception |
UAT khác demo ERP như thế nào?
Trong demo, consultant có thể chọn đường đi đẹp nhất. Trong UAT, business user phải tự chạy scenario đã định nghĩa, bao gồm ngoại lệ, với expected result và pass/fail rõ. UAT cũng phải ghi defect hoặc gap thay vì xử lý bằng giải thích miệng.
- Demo: chứng minh capability có thể tồn tại.
- UAT: chứng minh solution đã cấu hình cho doanh nghiệp hoạt động đúng theo acceptance criteria.
- Training: giúp user học cách vận hành; không thay UAT.
Bước 1: Xây test scope theo business risk
Không nên cố test mọi màn hình với mức ưu tiên như nhau. Hãy map critical process, financial/control impact, transaction volume, integration dependency và exception frequency để quyết định độ sâu test.
- Critical financial posting.
- Order-to-cash và procure-to-pay.
- Inventory movement và valuation.
- Production/MRP nếu có.
- Payroll hoặc compliance flow nếu in-scope.
- Integration critical với CRM/WMS/MES/bank.
- Role/permission và segregation of duties.
- Data migration/opening balance.
Bước 2: Viết test case có expected result
| Field | Nội dung |
|---|---|
| Test ID | Mã duy nhất để trace |
| Scenario | Business flow hoặc requirement |
| Precondition | Data, role, config cần có |
| Input | Dữ liệu cụ thể |
| Steps | Các bước thực hiện |
| Expected Result | Kết quả chấp nhận được |
| Actual Result | Kết quả thực tế |
| Status | Pass/Fail/Blocked |
| Evidence | Screenshot/log/document khi cần |
| Defect ID | Liên kết lỗi nếu fail |
Expected result phải mô tả outcome, không chỉ “hệ thống không báo lỗi”. Ví dụ invoice đúng amount, tax, accounting entry và status downstream.
Bước 3: Test dữ liệu và migration cùng business user
Migration validation cần kiểm tra không chỉ record count mà cả business meaning. Inventory phải reconcile theo item/warehouse/lot nếu cần; AR/AP theo open item/currency; GL theo account/dimension. Xem Data Migration ERP cho mapping, rehearsal và reconciliation.
Bước 4: Integration test phải có failure path
Đừng chỉ test happy path. Hãy test duplicate, retry, invalid payload, permission failure, service interruption, delayed message và reconciliation sau sync. Với interface critical, API 200 chưa đủ; business transaction phải xuất hiện đúng ở target.
Framework chi tiết nằm tại tích hợp ERP.
Bước 5: Security và permission test
- Positive test: role được phép thực hiện đúng task.
- Negative test: role không được phép bị chặn đúng.
- Approval delegation hoặc temporary access nếu có.
- Segregation of duties với các flow nhạy cảm.
- Audit log có ghi nhận event cần thiết.
Chỉ test “user đăng nhập được” không chứng minh access model đúng. Negative test là phần quan trọng để phát hiện quyền quá rộng.
Bước 6: Defect triage theo business impact
Severity không nên dựa vào cảm giác. Hãy phân loại theo khả năng hoàn thành critical process, data integrity, financial/control impact, workaround và số user bị ảnh hưởng.
| Severity | Ví dụ tiêu chí |
|---|---|
| Blocker/Critical | Critical process không chạy, data/control risk nghiêm trọng, không có workaround an toàn |
| High | Process quan trọng bị ảnh hưởng, workaround khó hoặc rủi ro cao |
| Medium | Ảnh hưởng hạn chế, có workaround chấp nhận được |
| Low | UI/cosmetic hoặc enhancement không chặn vận hành |
Definition cụ thể phải được steering team duyệt trước UAT để tránh hạ severity chỉ vì gần deadline.
Bước 7: Regression sau mỗi fix quan trọng
Một fix có thể ảnh hưởng flow khác, đặc biệt khi custom, workflow, pricing, tax hoặc integration dùng chung component. Regression set nên tập trung vào critical path và các area có dependency với thay đổi.
Bước 8: UAT sign-off phải dựa trên evidence
UAT sign-off không có nghĩa “mọi bug bằng 0”. Nó nghĩa business owner hiểu known issue, critical scenario đã pass hoặc có workaround được chấp nhận, và rủi ro còn lại nằm trong ngưỡng đã duyệt.
- Critical scenarios pass.
- Open defect có severity/owner/plan.
- Known workaround được document.
- Data test/reconciliation đạt acceptance.
- Critical integration pass end-to-end.
- Permission test pass.
- Business owner ký acceptance có điều kiện hoặc đầy đủ.
UAT có nên dùng production data?
Không mặc định. UAT cần dữ liệu đủ đại diện để test scenario thật, nhưng việc dùng dữ liệu production phải tuân thủ security/privacy và môi trường test. Có thể dùng masked/synthetic data hoặc subset phù hợp nếu vẫn giữ được business behavior cần kiểm chứng.
Checklist exit gate cho kiểm thử ERP
- Critical process và risk-based test scope đã khóa.
- Test case có expected result và owner.
- Migration/data reconciliation đã pass.
- Critical integration đã test failure path.
- Permission có positive và negative test.
- Blocker/Critical defect đã xử lý hoặc có quyết định no-go.
- Regression critical path đã hoàn thành.
- Known issue và workaround được document.
- UAT sign-off có evidence và business owner.
- Test evidence sẵn sàng cho go/no-go review.
Khi testing đạt exit criteria, bước tiếp theo là Go-live ERP & Cutover Checklist, nơi evidence từ UAT, migration, access và training được dùng cho quyết định go/no-go.
Kết luận
Kiểm thử ERP tốt biến requirement thành evidence: scenario, expected result, actual result, defect và sign-off đều có thể truy vết. UAT không phải nghi thức trước go-live; nó là một hard gate để business owner chấp nhận mức rủi ro còn lại trước khi hệ thống nhận giao dịch thật.
Đi tiếp từ UAT sang readiness và lifecycle
UAT cần nối hai chiều với các owner guide kế cận: Change Management ERP cho training/readiness và adoption, Bảo mật ERP cho permission/SoD negative test, Nâng cấp ERP cho regression sau release, Backup & Disaster Recovery ERP cho restore/DR validation và KPI ERP sau go-live để theo dõi defect, adoption và business outcome sau cutover.
Khi UAT thuộc phạm vi triển khai Odoo
Bài này tiếp tục sở hữu intent kiểm thử ERP và UAT vendor-neutral. Khi critical scenarios, defect triage, regression và business sign-off là một workstream trong dự án Odoo, xem dịch vụ triển khai Odoo để đặt UAT cùng blueprint, migration, integration, cutover và handover.
Đ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ả.
