Mở đầu — vì sao bài này quan trọng
Nếu bạn từng bị hỏi câu "Test cái này mất bao lâu?" và trả lời đại một con số để rồi ba tuần sau bị hỏi ngược lại "Sao trễ thế?", thì bạn đã trực tiếp nếm trải nỗi đau của Test Estimation — ước lượng nỗ lực kiểm thử. Đây là một trong những kỹ năng khó nhất và ít được dạy nhất trong nghề QA, nhưng lại là thứ quyết định trực tiếp uy tín của bạn với vai trò một QA Lead hay Test Manager.
Ước lượng sai không chỉ làm trễ dự án. Nó phá vỡ niềm tin. Khi bạn nói "hai tuần" mà thực tế mất năm tuần, Project Manager sẽ ngừng tin vào mọi con số bạn đưa ra sau đó, và tệ hơn, họ sẽ tự cắt thời gian test của bạn trong các dự án tiếp theo vì "QA lúc nào cũng phóng đại". Ngược lại, một QA Lead ước lượng đáng tin cậy sẽ được trao quyền quyết định release, được lắng nghe khi nói "chưa đủ thời gian test", và được xem như một đối tác thay vì một cái phanh.
Bài này tập trung riêng vào kỹ thuật ước lượng nỗ lực kiểm thử — làm sao biến một mớ yêu cầu mơ hồ thành một con số có cơ sở, bảo vệ được, và có thể điều chỉnh theo dữ liệu thực. Chúng ta sẽ không nói về việc viết Test Strategy hay Test Plan (đã có bài riêng), mà đi thẳng vào câu hỏi: bao nhiêu người, bao nhiêu ngày, và tại sao lại là con số đó.
Khái niệm cốt lõi
Vì sao ước lượng test lại khó đến vậy?
Trước khi học kỹ thuật, phải hiểu tại sao test khó ước lượng hơn code. Có ba lý do gốc rễ mà bất kỳ QA Lead nào cũng cần thuộc lòng:
Thứ nhất, test effort không tỷ lệ thuận với dev effort. Một tính năng developer code trong hai ngày có thể cần bảy ngày để test cho tử tế nếu nó là luồng thanh toán có nhiều nhánh điều kiện, tích hợp cổng payment, và ràng buộc pháp lý. Ngược lại, một tính năng dev code cả tuần có thể chỉ cần một buổi test nếu nó chỉ là thay đổi giao diện tĩnh. Ai ước lượng test bằng cách nhân dev effort với một hệ số cố định (kiểu "test bằng 30% dev") sẽ sai thường xuyên.
Thứ hai, vòng lặp sửa bug là không đoán trước được. Đây là phần bị bỏ quên nhiều nhất. Bạn không chỉ tốn thời gian tìm bug, mà còn tốn thời gian chờ dev sửa, rồi test lại (re-test), rồi kiểm tra hồi quy (regression) xem bản sửa có làm hỏng chỗ khác không. Một tính năng chất lượng code kém có thể khiến bạn lặp lại vòng "test — báo bug — chờ sửa — test lại" đến năm, sáu lần. Nếu không dự phòng cho vòng lặp này, mọi ước lượng đều lạc quan quá mức.
Thứ ba, phạm vi hồi quy phình to theo codebase. Khi sản phẩm còn nhỏ, regression chỉ mất một ngày. Sau hai năm phát triển, cũng chính sản phẩm đó có thể cần một tuần regression cho mỗi lần release, vì mỗi thay đổi nhỏ đều có nguy cơ ảnh hưởng đến hàng trăm chức năng đã có. Test effort vì thế tăng theo thời gian ngay cả khi khối lượng tính năng mới không đổi.
Bốn nhóm kỹ thuật ước lượng chính
Trong thực tế QA chuyên nghiệp, có bốn nhóm kỹ thuật bạn cần nắm. Không có kỹ thuật nào "đúng nhất" — chọn theo bối cảnh dự án.
1. Function Point / Work Breakdown (phân rã công việc). Đây là kỹ thuật nền tảng nhất. Bạn chia phạm vi test thành các đơn vị nhỏ có thể ước lượng riêng lẻ — thường là theo test case hoặc theo chức năng (function point) — rồi cộng lại. Ví dụ: đếm số test case dự kiến, nhân với thời gian trung bình để thiết kế và thực thi mỗi case, cộng thêm thời gian chuẩn bị dữ liệu và môi trường. Ưu điểm là minh bạch, dễ bảo vệ trước sếp. Nhược điểm là tốn công và đòi hỏi yêu cầu đã tương đối rõ.
2. Test Point Analysis (TPA). Một biến thể chuẩn hóa của cách trên, phổ biến trong môi trường doanh nghiệp lớn và outsourcing. TPA gán "điểm" cho mỗi chức năng dựa trên độ phức tạp, tầm quan trọng người dùng, và mức độ kiểm thử yêu cầu, sau đó nhân với năng suất đội (số test point làm được mỗi ngày). Nó có công thức rõ ràng nên rất hợp để báo giá hợp đồng.
3. Three-Point Estimation (PERT). Thay vì đưa một con số duy nhất, bạn đưa ba: Optimistic (tốt nhất, O), Most Likely (khả năng cao nhất, M), và Pessimistic (tệ nhất, P). Ước lượng cuối = (O + 4M + P) / 6. Kỹ thuật này cực kỳ giá trị cho test vì nó buộc bạn nghĩ đến kịch bản xấu — chính là những vòng lặp bug không đoán trước. Đây là công cụ tôi khuyên dùng nhất cho người mới lên QA Lead.
4. Analogous / Expert Judgment (loại suy và phán đoán chuyên gia). Dựa vào dữ liệu các dự án tương tự đã làm hoặc kinh nghiệm của người từng làm. "Dự án ngân hàng lõi năm ngoái tương tự dự án này, phần test mất sáu tuần, dự án này quy mô lớn hơn 20% nên ước tính bảy tuần rưỡi." Nhanh, nhưng chỉ đáng tin khi có dữ liệu lịch sử tốt và người ước lượng thực sự có kinh nghiệm.
Ba con số bạn không được quên
Dù dùng kỹ thuật nào, ước lượng test tử tế phải cộng đủ ba khoản mà người non tay hay quên: buffer cho re-test và regression (thường 20–40% tổng effort execution), thời gian chuẩn bị (viết test case, dựng môi trường, chuẩn bị test data — có thể chiếm 30–40% dự án), và thời gian chờ và giao tiếp (chờ build, chờ dev sửa, họp, làm rõ yêu cầu). Bỏ qua nhóm thứ ba là lý do số một khiến ước lượng "trên giấy" luôn ngắn hơn thực tế.
Tình huống thực tế
Ví dụ 1 — Startup fintech Sài Gòn và cái bẫy "test bằng một nửa dev"
Một startup ví điện tử ở TP.HCM (gọi là "PayNhanh") có đội 8 dev và 2 QA. QA Lead mới, tên Trang, được yêu cầu ước lượng test cho tính năng "nạp tiền qua thẻ tín dụng quốc tế". Team dev nói code mất 10 ngày. PM đề nghị Trang tính test bằng 50% dev, tức 5 ngày, và đã lỡ hứa với nhà đầu tư là ra mắt sau ba tuần.
Trang không đồng ý con số 5 ngày. Cô phân rã (Work Breakdown): luồng nạp tiền có thẻ Visa/Mastercard/JCB, mỗi loại có nhánh 3D-Secure và không 3D-Secure, có xử lý thất bại (thẻ hết hạn, không đủ tiền, timeout cổng thanh toán), có ràng buộc chống rửa tiền (giới hạn hạn mức). Cô đếm ra khoảng 140 test case. Với năng suất thực tế đội cô là ~20 case thực thi mỗi ngày cho mỗi QA, cộng thời gian viết case, dựng test data thẻ giả, và tích hợp môi trường sandbox của cổng thanh toán, cô ra con số 14 ngày cho 2 người, kèm buffer 30% cho vòng lặp bug vì tích hợp bên thứ ba luôn nhiều lỗi.
Diễn giải: PM ban đầu phản đối, nhưng Trang trình bảng phân rã. Con số không còn là "cảm tính của QA" mà là dữ liệu. Kết quả thực tế: mất 15 ngày — sát ước lượng của cô, và lệch hoàn toàn so với con số 5 ngày ban đầu.
Bài học: Đừng bao giờ chấp nhận ước lượng test theo tỷ lệ cố định của dev effort. Với tích hợp bên thứ ba và luồng tiền tệ, luôn phân rã chi tiết và cộng buffer lớn cho vòng lặp bug.
Ví dụ 2 — Công ty outsourcing Đà Nẵng và Three-Point Estimation
Một công ty gia công phần mềm ở Đà Nẵng nhận dự án test cho hệ thống quản lý kho của khách Nhật. Khách yêu cầu một con số cam kết. QA Manager, anh Dũng, biết rằng yêu cầu còn khá mơ hồ ở phần báo cáo tồn kho, nên anh dùng Three-Point Estimation cho từng module:
- Module quản lý nhập/xuất kho: O = 8 ngày, M = 12, P = 20 → (8 + 48 + 20)/6 = 12.7 ngày
- Module báo cáo (yêu cầu mơ hồ): O = 5, M = 10, P = 25 → (5 + 40 + 25)/6 = 11.7 ngày
Diễn giải: Kết quả cuối module báo cáo mất 14 ngày (khách chốt yêu cầu muộn) — nằm giữa M và P đúng như dự báo. Nhờ đã cảnh báo trước bằng con số P, không ai đổ lỗi cho đội QA.
Bài học: PERT không chỉ cho ra con số, nó là công cụ giao tiếp về rủi ro. Khoảng cách O–P rộng là tín hiệu bạn cần gửi ngược lại cho stakeholder để họ giảm bất định.
Ví dụ 3 — Sàn thương mại điện tử và cái giá của việc quên regression
Một sàn e-commerce tầm trung ở Hà Nội, sau hai năm phát triển, có codebase khổng lồ. QA Lead mới về ước lượng cho một sprint hai tuần chỉ tính thời gian test các tính năng mới trong sprint, ra con số 4 ngày, và tự tin cam kết. Anh hoàn toàn quên rằng mỗi lần release, họ phải chạy full regression suite cho toàn bộ luồng mua hàng, giỏ hàng, thanh toán, khuyến mãi — vốn đã tích tụ suốt hai năm và cần tới 5 ngày regression. Ước lượng 4 ngày, thực tế 9 ngày. Sprint vỡ kế hoạch.
Bài học: Test effort không chỉ là test tính năng mới. Với sản phẩm trưởng thành, phạm vi regression phình to theo thời gian và thường lớn hơn cả test tính năng mới. Luôn tách bạch hai khoản này khi ước lượng, và tự động hóa regression để kìm con số này lại.
Hướng dẫn từng bước
Đây là quy trình ước lượng test tôi khuyên dùng cho một QA Lead khi đứng trước một dự án hay một release:
Bước 1 — Làm rõ phạm vi và giả định. Trước khi ra bất kỳ con số nào, viết ra rõ ràng: test cái gì, không test cái gì, môi trường nào, thiết bị/trình duyệt nào, có bao gồm regression không, có bao gồm test hiệu năng/bảo mật không. Ghi lại mọi giả định (ví dụ: "giả định môi trường staging sẵn sàng ngày đầu"). Một ước lượng không có giả định đi kèm là một ước lượng vô nghĩa.
Bước 2 — Phân rã công việc. Chia phạm vi thành các đơn vị ước lượng được: theo module, theo user story, hoặc theo nhóm test case. Đừng ước lượng cả một khối lớn cùng lúc — não người luôn ước lượng khối lớn thiếu chính xác hơn nhiều khối nhỏ cộng lại.
Bước 3 — Chọn kỹ thuật phù hợp. Yêu cầu rõ ràng và có dữ liệu lịch sử → dùng Work Breakdown hoặc Analogous. Yêu cầu bất định cao → dùng Three-Point (PERT). Dự án hợp đồng cần công thức bảo vệ được → dùng Test Point Analysis.
Bước 4 — Ước lượng effort thô cho từng đơn vị. Với mỗi đơn vị: thời gian thiết kế test case + thời gian thực thi + thời gian chuẩn bị dữ liệu/môi trường. Dùng năng suất thực tế của đội bạn (số case/ngày đo từ dự án trước), không dùng con số lý tưởng.
Bước 5 — Cộng buffer cho re-test và regression. Cộng 20–40% cho vòng lặp báo bug — sửa — test lại. Tỷ lệ cao hơn cho phần code mới/tích hợp bên thứ ba, thấp hơn cho phần ổn định. Cộng riêng khoản regression cho toàn hệ thống.
Bước 6 — Cộng effort không phải test. Họp, làm rõ yêu cầu, chờ build, viết báo cáo, chờ dev. Nhóm này dễ chiếm 15–25% và luôn bị quên.
Bước 7 — Điều chỉnh theo năng lực đội. Đội có junior nhiều → cộng thời gian; có domain mới → cộng thời gian học. Chuyển từ "người-ngày" (effort) sang "ngày lịch" (duration) bằng cách chia cho số người và tính đến việc không ai làm 100% thời gian cho một dự án.
Bước 8 — Trình bày kèm độ tin cậy và ghi lại để đối chiếu. Đưa con số kèm khoảng dao động và giả định. Sau dự án, so sánh ước lượng với thực tế để hiệu chỉnh cho lần sau. Đây chính là vòng lặp biến bạn từ người đoán mò thành người ước lượng đáng tin.
Lỗi thường gặp & mẹo
Lỗi 1 — Ước lượng chỉ tính thời gian thực thi test. Người mới thường chỉ nghĩ "chạy test mất bao lâu" mà quên thiết kế test case, chuẩn bị test data, dựng môi trường. Ba khoản này thường lớn hơn cả thời gian thực thi.
Lỗi 2 — Bỏ qua re-test và regression. Đã nói ở trên nhưng phải nhắc lại vì đây là lỗi phổ biến nhất. Không có phần mềm nào pass ngay lần đầu; luôn dự phòng vòng lặp bug.
Lỗi 3 — Dùng năng suất lý tưởng thay vì thực tế. "Một QA làm được 30 case/ngày" nghe hay nhưng nếu dữ liệu thực của đội là 18 case/ngày (do có họp, có gián đoạn, có case phức tạp), thì phải dùng 18.
Lỗi 4 — Ước lượng một con số duy nhất cho yêu cầu mơ hồ. Nếu bất định cao mà bạn đưa một con số cứng, bạn sẽ luôn sai. Dùng khoảng hoặc PERT.
Lỗi 5 — Để bị ép cắt con số mà không cắt phạm vi. Khi sếp nói "làm trong nửa thời gian đi", đừng gật đầu suông. Hãy đáp lại: "Được, nhưng khi đó tôi sẽ bỏ test trên trình duyệt cũ và bỏ regression module X — chấp nhận rủi ro đó chứ?" Cắt thời gian phải đi kèm cắt phạm vi hoặc chấp nhận rủi ro rõ ràng.
Mẹo vàng: Luôn lưu lại số liệu ước lượng và thực tế của mọi dự án vào một bảng đơn giản. Sau năm sáu dự án, bạn sẽ có "hệ số hiệu chỉnh" của riêng đội mình — ví dụ "đội tôi luôn ước lượng thiếu 25%" — và chỉ cần nhân thêm là con số trở nên chính xác đến bất ngờ. Dữ liệu lịch sử là vũ khí mạnh nhất của người ước lượng.
Mẹo giao tiếp: Đừng bao giờ trình một con số trần trụi. Luôn kèm ba thứ: giả định, phạm vi bao gồm/loại trừ, và mức độ tin cậy. Điều này bảo vệ bạn khi thực tế lệch, và cho stakeholder thông tin để ra quyết định.
Bài tập thực hành
Bài 1 — Phân rã và ước lượng. Cho tính năng "đăng nhập bằng số điện thoại + OTP" cho một app Việt Nam. Hãy liệt kê các nhóm test case (luồng thành công, OTP sai, OTP hết hạn, gửi lại OTP, giới hạn số lần thử, số điện thoại không hợp lệ...). Ước lượng số test case, thời gian thiết kế và thực thi, cộng buffer 30%. Ghi rõ giả định của bạn.
Bài 2 — Three-Point Estimation. Cho một module báo cáo với yêu cầu mơ hồ. Bạn ước lượng O = 6 ngày, M = 10 ngày, P = 22 ngày. Tính con số PERT. Sau đó giải thích: khoảng cách O–P rộng như vậy nói lên điều gì, và bạn sẽ gửi thông điệp gì cho stakeholder?
Bài 3 — Bảo vệ ước lượng. PM yêu cầu bạn test một release trong 3 ngày, nhưng bạn tính ra cần 7 ngày (2 test tính năng mới, 5 regression). Hãy viết ba câu trả lời khác nhau: một câu đề xuất cắt phạm vi, một câu đề xuất chấp nhận rủi ro có kiểm soát, và một câu đề xuất giải pháp trung hạn để giảm con số 7 ngày này ở các release sau.
Bài 4 — Đối chiếu. Lấy một dự án bạn đã từng làm. Ước lượng ban đầu là bao nhiêu, thực tế là bao nhiêu? Lệch bao nhiêu phần trăm? Nguyên nhân lệch là gì — quên khoản nào, hay năng suất khác dự tính?
Tóm tắt
Ước lượng test khó vì ba lý do gốc: test effort không tỷ lệ với dev effort, vòng lặp sửa bug không đoán trước, và phạm vi regression phình to theo codebase. Muốn ước lượng đáng tin, bạn cần bốn nhóm kỹ thuật — Work Breakdown, Test Point Analysis, Three-Point (PERT), và Analogous/Expert Judgment — và chọn theo bối cảnh: yêu cầu rõ thì phân rã, yêu cầu mơ hồ thì dùng PERT, hợp đồng thì dùng công thức.
Dù dùng kỹ thuật nào, đừng bao giờ quên ba khoản người non tay hay bỏ sót: buffer cho re-test/regression, thời gian chuẩn bị (viết case, dựng data và môi trường), và thời gian chờ/giao tiếp. Luôn trình con số kèm giả định, phạm vi và độ tin cậy — không bao giờ đưa con số trần trụi. Và quan trọng nhất: lưu lại ước lượng so với thực tế của mọi dự án để xây dựng hệ số hiệu chỉnh riêng cho đội bạn. Chính vòng lặp học từ dữ liệu này biến một QA Lead từ người đoán mò thành người có những con số mà cả tổ chức tin tưởng — và đó là nền tảng của uy tín lãnh đạo QA.