Mở đầu — vì sao bài này quan trọng
Có một sự thật ít ai nói thẳng với các QA Manager mới lên: kỹ năng khiến bạn trở thành một tester giỏi gần như không giúp gì cho bạn khi bạn phải ngồi trước Giám đốc Tài chính (CFO) để bảo vệ ngân sách năm sau. Ở cấp độ leader, bạn không còn được đánh giá bằng số bug bạn tìm ra, mà bằng khả năng biến một khoản tiền hữu hạn thành năng lực đảm bảo chất lượng tối đa — và chứng minh được điều đó bằng con số.
Ngân sách QA (QA budget) là nơi mà chiến lược kiểm thử của bạn gặp thực tế tài chính của doanh nghiệp. Bạn có thể vẽ ra một chiến lược test hoàn hảo, nhưng nếu không có tiền để thuê người, mua công cụ, thuê thiết bị hay ký hợp đồng với vendor (nhà cung cấp dịch vụ bên ngoài), chiến lược đó chỉ là slide đẹp. Ngược lại, một QA Manager biết cách phân bổ, đàm phán và bảo vệ ngân sách sẽ có được thứ quyền lực thật sự trong tổ chức: quyền quyết định nguồn lực.
Bài này tập trung riêng vào hai mảng: (1) cấu trúc và quản trị ngân sách QA, và (2) quản lý vendor — từ chọn nhà cung cấp, đàm phán hợp đồng, đến kiểm soát chất lượng dịch vụ. Đây là kỹ năng "kinh doanh của QA", thứ phân biệt một Test Lead với một QA Director thực thụ.
Khái niệm cốt lõi
Các nhóm chi phí trong ngân sách QA
Một ngân sách QA lành mạnh thường được chia thành các nhóm chi phí (cost categories) sau. Đây là những tỷ lệ tham khảo mà tôi thấy đúng với đa số công ty phần mềm quy mô vừa tại Việt Nam và Đông Nam Á:
- Headcount (nhân sự): 60–75% tổng ngân sách. Đây là khoản lớn nhất và gần như luôn là như vậy. Nó bao gồm lương, thưởng, bảo hiểm, và các chi phí liên quan đến người (đào tạo, thiết bị làm việc). Với QA, con người vẫn là tài sản chính vì phần lớn giá trị đến từ tư duy kiểm thử, chứ không phải công cụ.
- Tools & SaaS (công cụ và dịch vụ phần mềm): 10–15%. Bao gồm license test management (như TestRail, Xray), automation framework thương mại, CI/CD add-on, công cụ quản lý defect, và các dịch vụ SaaS trả theo tháng.
- Device farm / Cloud testing (trang trại thiết bị / kiểm thử trên đám mây): 5–10%. Đặc biệt quan trọng với công ty làm mobile hoặc web đa trình duyệt. Bao gồm BrowserStack, Sauce Labs, LambdaTest, hoặc chi phí mua và duy trì thiết bị vật lý.
- Vendor / Outsourcing (thuê ngoài): 5–15%. Chi phí thuê đối tác kiểm thử bên ngoài, dù là theo dự án, theo giờ, hay theo mô hình đội ngũ chuyên trách (dedicated team).
- Training & Certification (đào tạo và chứng chỉ): 2–5%. ISTQB, khóa automation, hội thảo. Khoản này nhỏ nhưng đừng bao giờ cắt hết — nó là khoản đầu tư giữ người và nâng năng lực.
- Contingency (dự phòng): 5–10%. Khoản đệm cho những thứ bất ngờ: một release lớn phát sinh, một sự cố cần thuê pentest gấp, hay một công cụ tăng giá đột ngột.
CapEx và OpEx — ngôn ngữ của phòng tài chính
Bạn cần phân biệt được CapEx (Capital Expenditure — chi phí vốn) và OpEx (Operational Expenditure — chi phí vận hành). CapEx là những khoản đầu tư dài hạn, tài sản có giá trị sử dụng nhiều năm — ví dụ mua một dàn thiết bị test vật lý, hay xây một lab. OpEx là chi phí phát sinh đều đặn theo kỳ — lương, license SaaS hàng tháng, chi phí cloud theo mức dùng.
Xu hướng hiện nay nghiêng mạnh về OpEx: thay vì mua 50 chiếc điện thoại (CapEx, khấu hao nhanh, lỗi thời sau 2 năm), người ta thuê device farm trên cloud (OpEx, luôn có thiết bị mới). Khi trình bày với tài chính, biết dùng đúng thuật ngữ này khiến bạn trông đáng tin và giúp khoản chi được duyệt dễ hơn.
Vendor management — các mô hình thuê ngoài
Khi nói đến vendor, có ba mô hình hợp đồng chính bạn cần nắm:
- Time & Material (T&M — theo thời gian và nguồn lực): Trả theo giờ hoặc theo ngày công của người test. Linh hoạt, phù hợp khi phạm vi công việc chưa rõ. Rủi ro: chi phí dễ vượt tầm kiểm soát nếu không quản lý chặt.
- Fixed Price (giá cố định): Vendor cam kết một phạm vi công việc với một giá cố định. An toàn về ngân sách, nhưng kém linh hoạt — mọi thay đổi phạm vi đều phát sinh "change request" tốn tiền.
- Dedicated Team / Managed Service (đội ngũ chuyên trách / dịch vụ được quản lý): Vendor cung cấp một đội test làm việc lâu dài cho bạn, tính phí theo tháng. Phù hợp cho quan hệ dài hạn, kết hợp được ưu điểm của cả hai mô hình trên.
Tình huống thực tế
Tình huống 1 — Fintech Việt cắt vendor sai chỗ
Một công ty fintech tại TP.HCM (gọi là PayNow) có ngân sách QA năm khoảng 6 tỷ đồng. Cơ cấu ban đầu: 70% headcount (14 QA in-house), 8% tools, 7% cloud device, 12% vendor (một đối tác ở Đà Nẵng lo phần regression testing thủ công), 3% còn lại là đào tạo và dự phòng.
Năm khủng hoảng vốn, CFO yêu cầu cắt 15% ngân sách QA. QA Manager, dưới áp lực, quyết định cắt luôn toàn bộ khoản vendor 12% để giữ nguyên đội in-house. Nghe có vẻ hợp lý — "giữ người nhà, bỏ người ngoài". Nhưng vấn đề là đội vendor Đà Nẵng đang gánh toàn bộ regression testing cho 4 sản phẩm. Khi cắt, khối lượng đó dồn lên 14 QA in-house vốn đang lo feature testing. Kết quả: hai quý sau, tỷ lệ defect lọt ra production tăng 40%, có một sự cố sai số dư tài khoản khiến công ty phải bồi thường và chịu thanh tra nội bộ.
Bài học: Đừng cắt ngân sách theo cảm tính "trong nhà trước, ngoài sau". Hãy cắt theo giá trị trên mỗi đồng chi ra. Đội vendor Đà Nẵng thực ra có chi phí trên mỗi test case thấp hơn nhiều so với QA in-house ở TP.HCM. Nếu buộc phải cắt, đáng lẽ nên đàm phán lại hợp đồng vendor để giảm scope thay vì cắt sạch, hoặc chuyển một phần regression sang automation. Cắt sai chỗ khiến "tiết kiệm" 720 triệu nhưng thiệt hại gấp nhiều lần.
Tình huống 2 — Startup e-commerce và cái bẫy license không dùng hết
Một startup thương mại điện tử ở Hà Nội (Shoppe-clone giả định tên MuaNhanh) mua gói TestRail Enterprise cho 50 người dùng với giá khoảng 12.000 USD/năm, vì "sắp mở rộng đội QA lên 50 người". Thực tế một năm sau, đội QA chỉ có 18 người, và chỉ 11 người thực sự đăng nhập TestRail hàng tuần. Họ trả tiền cho 50 ghế nhưng dùng 11 ghế hiệu quả — tức khoảng 78% chi phí license đó là lãng phí.
Khi QA Lead làm một cuộc license audit (rà soát bản quyền), cô phát hiện thêm ba công cụ SaaS khác cũng trong tình trạng tương tự: một công cụ automation bản Pro không ai dùng vì đội đã chuyển sang Playwright (mã nguồn mở, miễn phí), và hai add-on Jira trùng chức năng. Tổng lãng phí lên tới gần 20.000 USD/năm — bằng gần nửa lương một QA Engineer.
Bài học: Chi phí Tools & SaaS âm thầm phình to vì nó là các khoản nhỏ, tự động gia hạn, không ai để ý. Hãy làm license audit ít nhất mỗi 6 tháng: đối chiếu số ghế mua với số người thực sự active, và rà soát trùng lặp chức năng. Với công cụ, nguyên tắc là "mua theo nhu cầu hiện tại + đệm nhỏ", không mua theo giấc mơ tăng trưởng.
Tình huống 3 — Đàm phán device farm theo mức dùng
Một công ty làm ứng dụng mobile cho ngân hàng ở Singapore ban đầu ký gói BrowserStack cố định 2.000 USD/tháng cho quyền truy cập không giới hạn. Sau 6 tháng, khi phân tích log sử dụng, họ thấy 80% lượng test tập trung vào 3 tuần cao điểm quanh các đợt release, còn lại các tuần dùng rất ít. QA Manager đàm phán lại chuyển sang mô hình kết hợp: một gói base nhỏ hơn (800 USD/tháng) cộng với phần trả theo mức dùng (pay-as-you-go) vào các đợt cao điểm. Tổng chi phí năm giảm khoảng 30%, tương đương tiết kiệm hơn 7.000 USD.
Bài học: Với cloud và device farm, hãy để dữ liệu sử dụng dẫn dắt quyết định. Đừng mặc định mua gói "unlimited" cho yên tâm — hãy đo pattern sử dụng thật rồi chọn mô hình phù hợp. Vendor luôn có nhiều gói hơn những gì họ chào bán đầu tiên; bạn phải chủ động hỏi.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn dùng để xây dựng và quản trị một ngân sách QA thực chiến:
Bước 1 — Bắt đầu từ chiến lược, không phải từ con số. Trước khi điền một dòng chi phí nào, hãy trả lời: năm nay QA hướng tới gì? Tăng automation? Mở rộng sang mobile? Đạt một mức maturity mới? Ngân sách phải phục vụ mục tiêu đó. Một ngân sách không gắn với mục tiêu là một danh sách mua sắm, không phải một kế hoạch.
Bước 2 — Lập baseline từ dữ liệu năm trước. Lấy chi phí thực tế năm trước theo từng nhóm (headcount, tools, cloud, vendor...). Đây là điểm xuất phát đáng tin cậy hơn nhiều so với ước lượng từ đầu. Ghi chú những khoản nào tăng, khoản nào giảm và vì sao.
Bước 3 — Phân bổ theo tỷ lệ và điều chỉnh theo bối cảnh. Dùng khung tỷ lệ ở trên làm điểm khởi đầu, rồi điều chỉnh. Đang đẩy automation? Tăng Tools, giảm headcount tương đối. Đang scale nhanh? Headcount lên trước.
Bước 4 — Gắn mỗi khoản chi với một kết quả đo được. Đây là bí quyết để bảo vệ ngân sách. Đừng viết "12.000 USD cho TestRail". Hãy viết "TestRail giúp quản lý 8.000 test case, giảm 20 giờ/tuần công tổng hợp báo cáo, phục vụ audit tuân thủ". Con số kết quả là thứ CFO muốn nghe.
Bước 5 — Xây dựng và chấm điểm shortlist vendor. Khi cần thuê ngoài, đừng chọn theo giá thấp nhất. Lập một bảng chấm điểm (scorecard) với các tiêu chí: năng lực kỹ thuật, kinh nghiệm domain, chất lượng nhân sự, khả năng scale, chi phí, và độ ổn định tài chính. Yêu cầu chạy một dự án thử nghiệm nhỏ (pilot) trước khi ký hợp đồng lớn.
Bước 6 — Đàm phán hợp đồng có SLA và điều khoản thoát. Luôn có SLA đo được và điều khoản cho phép bạn chấm dứt hợp đồng nếu vendor không đạt (exit clause). Đừng để bị khóa vào một vendor không thể thay thế.
Bước 7 — Theo dõi và rà soát định kỳ. Thiết lập một bảng theo dõi chi tiêu thực tế so với ngân sách (actual vs. budget) theo tháng hoặc quý. Làm license audit mỗi 6 tháng. Đánh giá vendor theo SLA mỗi quý.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi ngân sách QA là "chi phí" thay vì "đầu tư". Nếu bạn tự trình bày QA như một khoản tốn kém, tài chính sẽ luôn muốn cắt. Hãy trình bày QA như khoản bảo hiểm chống rủi ro: "mỗi đồng đầu tư vào QA giúp tránh X đồng chi phí sự cố production". Dùng dữ liệu cost-of-defect để chứng minh.
Lỗi 2 — Không có contingency. Ngân sách 100% chặt cứng sẽ vỡ ngay khi có bất ngờ. Luôn để dành 5–10% dự phòng.
Lỗi 3 — Chọn vendor rẻ nhất. Vendor rẻ thường có nhân sự yếu, turnover cao, và bạn tốn thời gian sửa việc của họ — "tiền nào của nấy" đúng một cách tàn nhẫn trong outsourcing QA. Hãy tính tổng chi phí sở hữu (total cost of ownership), gồm cả chi phí quản lý và rework.
Lỗi 4 — Khóa cứng vào một vendor duy nhất. Khi vendor biết bạn không có lựa chọn thay thế, quyền đàm phán về giá của bạn biến mất. Luôn giữ ít nhất một phương án dự phòng.
Lỗi 5 — Quên tính chi phí quản lý vendor. Quản lý một đội vendor tốn thời gian của chính bạn và team lead. Chi phí "vô hình" này phải nằm trong tính toán.
Mẹo hay:
- Đàm phán license theo năm thay vì theo tháng thường được giảm 15–20%.
- Yêu cầu vendor cung cấp báo cáo minh bạch theo SLA hàng tháng — cái gì không đo được thì không quản được.
- Với công cụ, luôn cân nhắc phương án mã nguồn mở (Playwright, Selenium, JMeter, k6) trước khi mua bản thương mại.
- Gộp các license SaaS trùng chức năng — thường mỗi công ty có 2–3 công cụ làm cùng một việc mà không ai để ý.
- Timing đàm phán: ký hợp đồng vào cuối quý của vendor, khi họ đang chạy chỉ tiêu doanh số, bạn dễ được giá tốt hơn.
Bài tập thực hành
Bài tập 1 — Lập ngân sách. Giả sử bạn là QA Manager của một công ty SaaS 30 người, ngân sách QA năm là 4 tỷ đồng, mục tiêu năm nay là tăng mức automation từ 20% lên 50%. Hãy phân bổ ngân sách theo 6 nhóm chi phí đã học, ghi rõ tỷ lệ và lý giải vì sao mục tiêu automation làm bạn điều chỉnh tỷ lệ so với mức mặc định.
Bài tập 2 — License audit. Liệt kê tất cả công cụ và dịch vụ SaaS mà đội QA hiện tại của bạn (hoặc một đội giả định) đang dùng. Với mỗi công cụ, ghi: số ghế mua, số người thực sự dùng, và có công cụ nào khác trùng chức năng không. Tính tổng số tiền có thể tiết kiệm.
Bài tập 3 — Vendor scorecard. Xây một bảng chấm điểm vendor với ít nhất 6 tiêu chí, gán trọng số cho từng tiêu chí (tổng 100%). Sau đó chấm điểm giả định cho 2 vendor và giải thích bạn chọn ai và tại sao — kể cả khi vendor bạn chọn không phải là bên rẻ nhất.
Bài tập 4 — Bảo vệ ngân sách. Viết một đoạn 5–7 câu để bảo vệ khoản chi 15.000 USD/năm cho một cloud device farm trước CFO đang muốn cắt. Bắt buộc dùng ít nhất hai con số kết quả cụ thể (ví dụ số thiết bị hỗ trợ, số giờ tiết kiệm, rủi ro tránh được).
Tóm tắt
Quản lý ngân sách và vendor là kỹ năng "kinh doanh của QA" — nơi chiến lược kiểm thử va chạm với thực tế tài chính. Ba điều cốt lõi cần nhớ:
Thứ nhất, ngân sách phản ánh chiến lược. Cơ cấu chi phí (headcount 60–75%, tools 10–15%, cloud 5–10%, vendor 5–15%, cộng đào tạo và dự phòng) không phải công thức cứng mà là hệ quả của mục tiêu QA năm đó. Hãy bắt đầu từ chiến lược, gắn mỗi khoản chi với một kết quả đo được, và luôn giữ 5–10% dự phòng.
Thứ hai, cắt ngân sách phải theo giá trị trên mỗi đồng, không theo cảm tính. Tình huống PayNow cho thấy cắt vendor sai chỗ có thể gây thiệt hại gấp nhiều lần khoản tiết kiệm. Tình huống MuaNhanh nhắc rằng chi phí SaaS âm thầm phình to — hãy audit định kỳ.
Thứ ba, quản lý vendor là chọn đúng, ký chặt, và theo dõi liên tục. Chọn theo scorecard và pilot chứ không theo giá rẻ nhất; ký hợp đồng có SLA đo được và điều khoản thoát; giữ phương án dự phòng để không bị khóa cứng. Và trên hết, hãy trình bày QA như một khoản đầu tư chống rủi ro, không phải một khoản chi phí — đó là cách bạn giữ được ngân sách qua mọi mùa khủng hoảng.