1. Tổng quan — Khi nhà cung cấp nói "xong rồi"
Sau khi dữ liệu đã sạch (Bài 5), nhà cung cấp triển khai ERP báo cáo: "Hệ thống đã cài đặt xong, sẵn sàng vận hành." Giám đốc Việt Solution suýt tin và muốn go-live ngay. Nhưng kế toán trưởng — người cẩn thận hơn — đề nghị: "Để tôi thử chạy song song 1 tháng trước. Nếu ERP kê khai giống Excel cũ, mới chuyển hẳn."
Đề nghị đó đã cứu công ty. Trong tháng chạy thử, kế toán trưởng phát hiện 23 lỗi — từ lỗi nghiêm trọng (tính sai thuế GTGT đầu vào) đến lỗi nhỏ (ngày tháng hiển thị sai định dạng). Nếu go-live ngay mà không kiểm tra, tháng đầu tiên sẽ nộp sai tờ khai cho 120 khách hàng — tai họa lớn hơn bất kỳ lỗi nào trước đây.
Bài này kể chi tiết cách Việt Solution thiết kế chiến lược kiểm thử (testing) — không phải kiểm thử như dân IT làm, mà kiểm thử như người kế toán thật sự dùng.
2. Thách thức — ERP "chạy được" chưa chắc "chạy đúng"
2.1 Khoảng cách giữa "demo tốt" và "thực tế đúng"
Khi nhà cung cấp demo, mọi thứ chạy mượt. Nhưng demo dùng dữ liệu lý tưởng — 5 khách hàng, mỗi người 3 hóa đơn, số tiền tròn. Thực tế của Việt Solution: 120 khách hàng, mỗi người 20-30 chứng từ, số tiền lẻ, nhiều ngoại lệ.
Hệ thống chạy được trên dữ liệu lý tưởng chưa chắc chạy đúng trên dữ liệu thật. Ví dụ cụ thể mà kế toán trưởng phát hiện: ERP tính thuế GTGT đầu vào của hóa đơn có "chiết khấu thương mại" sai — demo không có trường hợp này nên không lộ ra.
2.2 Bốn loại lỗi cần phát hiện
Ban dự án phân loại lỗi cần kiểm tra thành 4 nhóm:
| Loại lỗi | Mức độ | Ví dụ |
|---|---|---|
| Lỗi tính toán sai | Nghiêm trọng | Tính sai thuế, sai tổng tiền |
| Lỗi quy trình | Nghiêm trọng | Không nhắc deadline, không khóa tờ khai |
| Lỗi hiển thị | Trung bình | Ngày sai định dạng, số tiền thiếu dấu chấm |
| Lỗi tiện ích | Nhỏ | Chậm khi nhiều người dùng cùng lúc |
Lỗi tính toán sai là nguy hiểm nhất — vì nó dẫn đến nộp sai thuế, hậu quả pháp lý. Phải phát hiện 100% trước khi go-live.
2.3 Không có thời gian kiểm tra hết
Lý tưởng nhất là kiểm tra tất cả 120 khách hàng × tất cả quy trình. Nhưng thực tế không đủ thời gian và nhân lực. Việt Solution phải chọn đại diện — kiểm tra một nhóm mẫu, giả định rằng nếu mẫu đúng thì toàn bộ khả năng cao cũng đúng.
3. Giải pháp — Chiến lược kiểm thử 3 lớp
Việt Solution áp dụng 3 lớp kiểm thử, mỗi lớp có mục tiêu khác nhau.
Lớp 1: Kiểm thử tính năng (Feature Testing) — Nhà cung cấp làm
Nhà cung cấp chịu trách nhiệm kiểm tra mỗi tính năng có hoạt động đúng thiết kế không. Ví dụ:
- Tính năng "nhắc deadline": tạo deadline thử, kiểm tra email nhắc có gửi không
- Tính năng "khóa tờ khai": nộp tờ khai, thử sửa lại, kiểm tra có bị chặn không
- Tính năng "dashboard": kiểm tra số liệu trên dashboard khớp với dữ liệu gốc không
Kết quả lớp 1: nhà cung cấp tự phát hiện và sửa 45 lỗi trước khi bàn giao. Đây là bước lọc đầu tiên — lỗi thô nhất được loại.
Lớp 2: Kiểm thử nghiệp vụ (Business Testing) — Nội bộ làm
Đây là lớp quan trọng nhất, do kế toán trưởng và 2 kế toán viên giỏi nhất thực hiện. Họ không kiểm tra "tính năng có chạy không" — mà kiểm tra "kết quả có đúng không".
Cách làm: chọn 10 khách hàng đại diện (đại diện cho các loại hình doanh nghiệp, quy mô, ngành nghề khác nhau), chạy toàn bộ quy trình kê khai tháng trên ERP, rồi so sánh kết quả với Excel cũ.
| Khách hàng đại diện | Đặc điểm | Lý do chọn |
|---|---|---|
| Khách 1-3 | Doanh nghiệp thương mại | Có hóa đơn đầu vào/đầu ra nhiều |
| Khách 4-5 | Doanh nghiệp dịch vụ | Ít hóa đơn, nhiều ngoại lệ |
| Khách 6-7 | Doanh nghiệp sản xuất | Có chi phí phức tạp |
| Khách 8-9 | Hộ kinh doanh cá thể | Quy mô nhỏ, quy trình đơn giản |
| Khách 10 | Khách đặc biệt | Có tranh chấp thuế, cần lưu ý |
Mỗi khách hàng được kiểm tra theo danh sách kiểm tra (checklist) gồm 15-20 điểm:
□ Tổng thuế GTGT đầu ra khớp Excel? (±0đ)
□ Tổng thuế GTGT đầu vào khớp Excel? (±0đ)
□ Thuế TNDN tạm tính khớp? (±1%)
□ Danh sách hóa đơn đầy đủ? (số lượng khớp)
□ Ngày tháng hiển thị đúng định dạng DD/MM/YYYY?
□ Tên khách hàng hiển thị đúng (VIẾT HOA)?
□ Số tài khoản ngân hàng đúng?
□ ...Kết quả lớp 2: phát hiện 18 lỗi — trong đó 3 lỗi nghiêm trọng (tính sai thuế) và 15 lỗi trung bình/nhỏ. Toàn bộ phải sửa trước khi chuyển sang lớp 3.
Lớp 3: Kiểm thử chạy song song (Parallel Run) — Thử thách thật
Đây là lớp kiểm tra triệt để nhất: chạy ERP song song với Excel trong 1 tháng thật. Nghĩa là mọi công việc được làm 2 lần — 1 lần trên Excel (như cũ), 1 lần trên ERP (như mới). Cuối tháng, so sánh kết quả.
Vì sao tốn công nhưng phải làm? Vì lớp 1 và 2 chỉ kiểm tra dữ liệu mẫu — có thể bỏ sót tình huống thực tế. Lớp 3 dùng dữ liệu thật, tình huống thật, áp lực thật. Lỗi lộ ra ở lớp 3 là lỗi chỉ xảy ra trong điều kiện vận hành thật.
Kết quả lớp 3: phát hiện thêm 5 lỗi — phần lớn là lỗi chỉ xảy ra khi nhiều người dùng cùng lúc (ví dụ: 5 kế toán viên cùng nhập liệu thì ERP chậm đi).
Tổng kết 3 lớp
| Lớp | Người làm | Số lỗi phát hiện | Mục tiêu |
|---|---|---|---|
| Lớp 1: Tính năng | Nhà cung cấp | 45 | Tính năng chạy được |
| Lớp 2: Nghiệp vụ | Nội bộ (10 khách mẫu) | 18 | Kết quả đúng |
| Lớp 3: Song song | Toàn bộ (1 tháng thật) | 5 | Chịu được thực tế |
| Tổng cộng | 68 lỗi |
68 lỗi được sửa hết trước khi go-live. Nếu không có 3 lớp kiểm thử, các lỗi này sẽ lộ ra sau go-live — khi khách hàng đã phụ thuộc vào ERP và không thể rollback.
4. Quy trình xử lý lỗi — Không phải sửa là xong
Khi phát hiện lỗi, không phải cứ "báo nhà cung cấp sửa" là xong. Việt Solution thiết lập quy trình xử lý lỗi bài bản:
Bước 1: Ghi nhận có hệ thống
Mỗi lỗi được ghi vào bảng theo dõi lỗi (bug tracker) — một Google Sheet đơn giản với các cột:
| Mã lỗi | Mô tả | Mức độ | Người phát hiện | Ngày | Trạng thái |
|---|---|---|---|---|---|
| BUG-001 | Tính sai GTGT đầu vào khi có chiết khấu | Nghiêm trọng | Kế toán trưởng | 15/06 | Đang sửa |
| BUG-002 | Ngày hiển thị MM/DD/YYYY thay vì DD/MM/YYYY | Nhỏ | Kế toán viên A | 16/06 | Đã sửa |
Bảng theo dõi này đảm bảo không lỗi nào bị quên — vì mỗi lỗi có mã, có người chịu trách nhiệm, có trạng thái rõ ràng.
Bước 2: Phân loại mức độ ưu tiên
Không phải lỗi nào cũng phải sửa ngay. Phân loại:
- Nghiêm trọng (Critical): Lỗi tính toán sai, lỗi quy trình then chốt → phải sửa trước go-live, không ngoại lệ
- Trung bình (Medium): Lỗi hiển thị, lỗi tiện ích → sửa trong vòng 1 tháng sau go-live
- Nhỏ (Low): Lỗi thẩm mỹ, lỗi hiếm gặp → ghi nhận, sửa khi rảnh
Bước 3: Xác nhận đã sửa
Khi nhà cung cấp báo "đã sửa", không tin ngay. Phải kiểm tra lại — chạy lại tình huống gây lỗi, xem có còn bị không. Nếu còn, báo lại, không chấp nhận "đã sửa" bằng lời.
Nguyên tắc: lỗi chỉ được đóng khi người phát hiện xác nhận đã hết — không phải khi nhà cung cấp nói đã sửa.
Bước 4: Kiểm tra không tái diễn
Khi một lỗi được sửa, cần kiểm tra xem việc sửa có gây ra lỗi mới không. Ví dụ: sửa lỗi định dạng ngày → vô tình làm hỏng tính năng xuất Excel. Đây là "lỗi dây chuyền" — sửa chỗ này làm hỏng chỗ kia.
Quy định: sau mỗi lần sửa lỗi nghiêm trọng, phải chạy lại toàn bộ checklist lớp 2 để đảm bảo không có hồi quy (regression).
5. Sai lầm gần mắc — Go-live vội
Khoảng giữa giai đoạn kiểm thử, áp lực thời gian lớn — khách hàng đợi, nhà cung cấp hối, giám đốc sốt ruột. Có một khoảnh khắc giám đốc tính nói: "Đã sửa hết lỗi nghiêm trọng rồi, go-live luôn, lỗi nhỏ sửa sau."
May mà kế toán trưởng can ngăn: "3 lỗi nghiêm trọng đã sửa, nhưng chưa kiểm tra hồi quy. Nếu go-live mà sửa lỗi này gây ra lỗi khác, chúng ta nộp sai thuế cho 120 khách hàng cùng lúc. Không đáng."
Giám đốc nghe, đồng ý chờ thêm 1 tuần để kiểm tra hồi quy toàn diện. Trong tuần đó, phát hiện 2 lỗi hồi quy do việc sửa lỗi trước gây ra — nếu go-live vội, hậu quả khó lường.
Bài học: lỗi nhỏ có thể sửa sau, nhưng lỗi nghiêm trọng phải sửa sạch trước go-live. Một tuần chờ đợi rẻ hơn rất nhiều so với một tháng sửa sai sau go-live.
6. Kết quả — 68 lỗi sửa trước khi go-live
| Chỉ số | Số liệu |
|---|---|
| Tổng số lỗi phát hiện | 68 |
| Lỗi nghiêm trọng | 8 (sửa hết trước go-live) |
| Lỗi trung bình | 25 (20 sửa trước, 5 sửa sau 1 tháng) |
| Lỗi nhỏ | 35 (sửa trong 3 tháng) |
| Thời gian kiểm thử tổng | 6 tuần |
| Lỗi tái diễn sau khi sửa | 2 (phát hiện và sửa kịp) |
| Lỗi sau go-live | 3 (không nghiêm trọng) |
Tác động
Nhờ kiểm thử bài bản, chỉ 3 lỗi nhỏ xuất hiện sau go-live — đều là lỗi hiển thị, không ảnh hưởng tính toán. Nếu không kiểm thử, ước tính sẽ có 20-30 lỗi xuất hiện sau go-live, trong đó có thể có 5-8 lỗi nghiêm trọng tính sai thuế — hậu quả tai tiếng với khách hàng và cơ quan thuế.
7. Bài học rút ra
7.1 Dành cho công ty dịch vụ kế toán thuế
- Kiểm thử là bảo hiểm, không phải chi phí: 6 tuần kiểm thử có vẻ dài, nhưng rẻ hơn nhiều so với 1 lỗi tính sai thuế đi vào thực tế. Trong ngành kế toán thuế, sai sót có hậu quả pháp lý — kiểm thử là cách phòng ngừa
- Kiểm thử nghiệp vụ quan trọng hơn kiểm thử tính năng: Đừng chỉ tin nhà cung cấp khi họ nói "tính năng chạy được". Hãy tự kiểm tra "kết quả có đúng không" — bằng cách so sánh với Excel cũ
- Chạy song song 1 tháng là bắt buộc: Đây là cách duy nhất để phát hiện lỗi chỉ xảy ra trong điều kiện vận hành thật. Tốn công (làm 2 lần) nhưng xứng đáng
- Lỗi chỉ đóng khi người phát hiện xác nhận: Đừng tin "đã sửa" bằng lời. Phải kiểm tra lại, và phải kiểm tra không hồi quy
7.2 Lời khuyên từ Kế toán trưởng Việt Solution
"Tôi đã làm kế toán 15 năm, biết rõ 'số liệu phải khớp từng đồng'. Khi nhà cung cấp nói 'ERP tính đúng rồi', tôi không tin — tôi phải tự kiểm tra. Và tôi đã tìm ra lỗi tính sai GTGT khi có chiết khấu thương mại, lỗi mà demo không bao giờ lộ ra vì demo không có trường hợp đó. Bài học của tôi: trong kế toán, đừng tin ai — tin con số. Nếu ERP ghi 1.234.567đ mà Excel ghi 1.234.576đ, phải tìm ra tại sao. 9 đồng chênh lệch có thể là dấu hiệu của một lỗi tính toán lớn hơn ẩn phía sau."
8. Kết luận
Kiểm thử ERP không phải việc của dân IT — trong công ty dịch vụ kế toán thuế, nó là việc của người làm kế toán thật sự. Chỉ người hiểu nghiệp vụ mới phát hiện được lỗi tính toán sai, lỗi quy trình sai — những lỗi mà kỹ sư phần mềm không nhìn ra vì họ không biết "số nào mới đúng".
Câu chuyện của Việt Solution cho thấy: đừng vội go-live. 6 tuần kiểm thử đã giúp công ty tránh được 20-30 lỗi sau go-live, trong đó có thể có lỗi nghiêm trọng dẫn đến nộp sai thuế. Chi phí 6 tuần rẻ hơn rất nhiều so với chi phí sửa sai sau khi khách hàng đã bị ảnh hưởng.
Bài tiếp theo (Bài 7) sẽ kể về khoảnh khắc quan trọng nhất — go-live: ngày ERP chính thức thay thế Excel, những việc làm trong tuần đầu tiên, và cách xử lý khi sự cố xảy ra.
Nguyên tắc vàng: "Trong kế toán thuế, một con số sai có thể dẫn đến phạt, dẫn đến mất khách, dẫn đến kiện tụng. Kiểm thử ERP không phải tùy chọn — đó là nghĩa vụ. Đừng go-live khi chưa kiểm tra từng đồng, từng ngày, từng tờ khai. Chậm 1 tuần an toàn hơn nhanh 1 ngày hối hận."