Chiến lược kiểm thử & Kế hoạch kiểm thử (Test Strategy & Test Plan) cho dự án ERP doanh nghiệp: cấu trúc, tiêu chí vào/ra, ước lượng công sức (có trắc nghiệm)

1. Tóm tắt nhanh & tài liệu bạn sẽ viết

Ở một dự án web thông thường, 'test xong chưa' đôi khi chỉ cần vài dòng chat. Nhưng ở một dự án triển khai ERP như OneERP — nơi số liệu kế toán, tồn kho và doanh thu của cả tập đoàn phụ thuộc vào đúng một hệ thống — câu hỏi đó cần một câu trả lời có thể chứng minh được bằng tài liệu, không phải cảm tính của một cá nhân. Đó chính là vai trò của cặp tài liệu Test Strategy và Test Plan: strategy định hình 'chúng ta kiểm thử theo triết lý nào' ở mức chương trình, còn plan biến triết lý đó thành những con số, mốc thời gian và tiêu chí cụ thể cho riêng dự án OneERP.

2. Test Strategy vs Test Plan: phân biệt rõ ràng

Cách dễ nhớ nhất: Test Strategy sống ở mức TỔ CHỨC hoặc CHƯƠNG TRÌNH — nó ít khi đổi, dùng chung cho nhiều dự án (ví dụ 'mọi dự án của tập đoàn Đại Việt đều phải có UAT do đại diện phòng ban ký, mọi module tài chính đều bắt buộc kiểm thử hồi quy tự động'). Test Plan sống ở mức DỰ ÁN — nó cụ thể, có ngày tháng, có tên người, và chỉ áp dụng cho chính dự án OneERP Release 1: 'UAT diễn ra tuần 6–7, do chị Lan (BA Tài chính) và anh Huy (BA Kho) ký nghiệm thu'.

Một cách hình dung khác: nếu Test Strategy là 'hiến pháp kiểm thử' của cả tổ chức, thì Test Plan là 'luật thi hành' cho từng dự án cụ thể — phải tuân theo hiến pháp, nhưng có chi tiết riêng phù hợp bối cảnh của dự án đó. Nhiều đội mới thường nhầm lẫn hai tài liệu này, viết một bản duy nhất chung chung rồi dùng cho mọi dự án — hậu quả là test plan thiếu hẳn những con số cụ thể (tiêu chí vào/ra, lịch trình, người phụ trách) cần thiết để thực sự điều hành việc kiểm thử hằng ngày.

3. Vì sao OneERP cần chiến lược & kế hoạch kiểm thử bài bản

OneERP không phải một ứng dụng đơn lẻ — nó là trung tâm thần kinh vận hành của Tập đoàn bán lẻ Đại Việt: module Tài chính (FI) đóng sổ kế toán toàn tập đoàn, module Kho (MM) theo dõi tồn kho thật tại 240 cửa hàng, module Bán hàng (SD) xử lý đơn hàng và giá, và lớp tích hợp POS đồng bộ từng giao dịch tại quầy thu ngân về hệ thống trung tâm theo thời gian thực. Một lỗi nhỏ ở tầng tích hợp — ví dụ đồng bộ POS chậm 30 giây — có thể nhân bản thành sai lệch tồn kho ở hàng trăm cửa hàng cùng lúc.

Vì OneERP chạm vào TIỀN (doanh thu, chi phí, công nợ), TỒN KHO thật (không thể 'hoàn tác' hàng đã bán), và số liệu BÁO CÁO cho ban lãnh đạo/kiểm toán, một chiến lược kiểm thử rõ ràng ở mức chương trình giúp mọi dự án ERP tương lai của tập đoàn không phải 'phát minh lại bánh xe' mỗi lần; và một kế hoạch kiểm thử chi tiết cho riêng Release 1 giúp đội dự án biết chính xác khi nào một pha kiểm thử thực sự hoàn tất, thay vì bị cuốn theo áp lực deadline như tình huống ở chương 7.

Nói cách khác, chiến lược và kế hoạch kiểm thử ở một dự án ERP không phải thủ tục hành chính cho có — chúng là hàng rào kiểm soát cuối cùng trước khi một con số sai chảy vào báo cáo tài chính của cả tập đoàn.

4. Chuẩn bị: cấu trúc chuẩn của một Test Plan

Trước khi viết, bạn cần một khung sườn chuẩn để không bỏ sót mục nào. Nhiều tổ chức tham chiếu cấu trúc kiểu IEEE 829 / ISO 29119 — dưới đây là 10 mục cốt lõi, cụ thể hoá cho OneERP.

▶ Bước 1: Viết mục 1–3 trước: giới thiệu/mục tiêu, phạm vi trong/ngoài, và danh sách đối tượng kiểm thử cụ thể (luồng nghiệp vụ, không phải tên màn hình).

▶ Bước 2: Viết mục 4–6: cách tiếp cận (tham chiếu Test Strategy của tập đoàn), tiêu chí vào/ra, môi trường & công cụ.

▶ Bước 3: Viết mục 7–10: lịch trình, phân công RACI, rủi ro & phương án dự phòng, sản phẩm bàn giao — rồi trình bản nháp cho Test Manager và PM cùng review.