Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là QA lead của một dự án. Sáng thứ Hai, Project Manager (PM) gọi bạn vào phòng họp và hỏi một câu tưởng chừng đơn giản: "Anh cần bao nhiêu ngày để test xong module thanh toán này?". Nếu bạn trả lời "khoảng một tuần" theo cảm tính, rồi thực tế mất ba tuần, bạn không chỉ làm chậm cả dự án mà còn đánh mất niềm tin của team. Ngược lại, nếu bạn "phòng thủ" bằng cách hét lên một con số thật lớn cho an toàn, PM sẽ nghi ngờ năng lực của bạn và có thể cắt bớt phạm vi test.
Ước lượng (estimation) là một trong những kỹ năng phân biệt rõ nhất giữa một tester và một QA chuyên nghiệp. Tester chỉ biết chạy test case; QA chuyên nghiệp biết dự báo cần bao nhiêu công sức, thời gian, và con người để đảm bảo chất lượng — rồi bảo vệ con số đó bằng dữ liệu.
Cụ thể, ước lượng test quan trọng vì ba lý do lớn:
- Cam kết deadline với PM và stakeholder. Con số ước lượng của bạn trở thành một phần của kế hoạch dự án. Sai lệch của bạn kéo theo sai lệch của cả team.
- Đàm phán nguồn lực. Khi bạn ước lượng cần 40 người-ngày (person-days) nhưng chỉ có 2 tuần với 1 người, bạn có cơ sở để yêu cầu thêm QA, hoặc để đề xuất cắt giảm phạm vi.
- Lập ngân sách cho dự án outsource. Ở các công ty gia công phần mềm Việt Nam như FPT Software, KMS Technology hay TMA Solutions, ước lượng sai một dự án fixed-price có thể khiến công ty lỗ trực tiếp bằng tiền mặt.
Khái niệm cốt lõi
Ước lượng là gì và không phải là gì
Ước lượng là dự báo có căn cứ về công sức cần thiết, thường tính bằng đơn vị person-days (người-ngày) hoặc person-hours (người-giờ). Điểm mấu chốt: ước lượng không phải là lời hứa chắc chắn 100%, mà là một khoảng tin cậy. Một QA giỏi luôn trình bày ước lượng kèm giả định (assumptions) và mức độ rủi ro, thay vì đưa một con số cứng nhắc như thể đó là chân lý.
Cần phân biệt ba khái niệm hay bị nhầm:
- Effort (công sức): tổng lượng công việc, ví dụ 40 person-days.
- Duration (thời lượng): thời gian thực tế trôi qua, phụ thuộc số người. 40 person-days với 2 người song song ≈ 20 ngày lịch.
- Cost (chi phí): effort nhân với đơn giá nhân sự.
Bốn kỹ thuật ước lượng phổ biến
1. Work Breakdown Structure (WBS) — Ước lượng phân rã
Đây là kỹ thuật nền tảng nhất. Bạn chia nhỏ toàn bộ công việc test thành các đầu việc con đủ nhỏ để ước lượng chính xác, rồi cộng lại. Ví dụ, thay vì ước lượng "test module đăng nhập", bạn phân rã thành: thiết kế test case (4h), review test case (1h), chuẩn bị test data (2h), thực thi (6h), báo cáo bug và retest (4h). Cộng lại được 17 giờ.
WBS mạnh vì nó buộc bạn nghĩ đến mọi hoạt động, kể cả những việc dễ quên như setup môi trường hay retest sau khi fix. Nhược điểm: tốn thời gian và đòi hỏi bạn hiểu rõ phạm vi.
2. Ước lượng theo Test Case (Test Case Point / theo năng suất)
Kỹ thuật này dựa trên năng suất lịch sử: trung bình đội bạn thiết kế được bao nhiêu test case mỗi ngày, và thực thi được bao nhiêu test case mỗi ngày. Ví dụ, nếu năng suất là 20 test case thiết kế/ngày và 30 test case thực thi/ngày, một module dự kiến 300 test case sẽ cần 15 ngày thiết kế + 10 ngày thực thi = 25 person-days (chưa tính retest).
Điểm hay là rất dễ giải thích cho PM. Điểm yếu: test case có độ phức tạp khác nhau — một test case luồng thanh toán không thể tính ngang một test case kiểm tra ô nhập trống. Nhiều đội khắc phục bằng cách phân loại test case theo độ phức tạp (Simple/Medium/Complex) với hệ số khác nhau.
3. Ước lượng ba điểm — Three-Point / PERT
Đây là kỹ thuật xử lý sự không chắc chắn một cách khoa học. Với mỗi đầu việc, bạn đưa ba con số:
- O (Optimistic): trường hợp thuận lợi nhất.
- M (Most likely): trường hợp khả dĩ nhất.
- P (Pessimistic): trường hợp xấu nhất.
E = (O + 4M + P) / 6
Ví dụ, test module tìm kiếm: O = 3 ngày, M = 5 ngày, P = 11 ngày. Thì E = (3 + 20 + 11) / 6 = 5.67 ngày. Con số này "an toàn" hơn 5 vì đã tính đến rủi ro đuôi dài của kịch bản P. PERT đặc biệt hữu ích khi phạm vi còn mơ hồ.
4. Ước lượng theo chuyên gia & tương tự (Expert Judgment / Analogous)
Bạn dựa vào kinh nghiệm của người từng làm việc tương tự, hoặc so sánh với dự án quá khứ có đặc điểm giống. "Dự án e-commerce lần trước module giỏ hàng mất 12 ngày, dự án này tương tự nên ước 12–14 ngày". Đây là kỹ thuật nhanh nhất, phù hợp giai đoạn đầu khi chưa có đủ thông tin, nhưng độ chính xác phụ thuộc hoàn toàn vào kinh nghiệm người ước lượng và mức độ giống nhau thật sự giữa hai dự án.
Đừng quên hệ số điều chỉnh (Buffer & Overhead)
Con số "thuần túy" chưa phải con số cuối. Bạn cần cộng thêm:
- Buffer rủi ro: thường 10–20% cho những điều không lường trước.
- Overhead: họp, đào tạo, viết báo cáo, giao tiếp — thường chiếm 15–25% thời gian thực tế của tester.
- Thời gian phi năng suất: không ai làm việc 100% 8 tiếng/ngày. Thực tế năng suất hiệu quả chỉ khoảng 6–6.5 giờ.
Tình huống thực tế
Tình huống 1: Dự án fixed-price tại một công ty outsource ở TP.HCM
Một công ty gia công phần mềm quy mô vừa ở TP.HCM (gọi là VStar Software) nhận hợp đồng test một ứng dụng đặt lịch khám bệnh cho khách hàng Singapore, theo mô hình fixed-price 300 triệu đồng. QA lead Minh ban đầu ước lượng bằng expert judgment: "Ứng dụng vừa vừa, chắc 25 ngày là xong", và chốt luôn với sales.
Thực tế phát sinh: khách hàng yêu cầu test trên 3 trình duyệt, 2 hệ điều hành mobile, có cả luồng thanh toán và tích hợp SMS OTP. Đội test phải mất 47 ngày. Vì là fixed-price, phần chênh lệch 22 ngày công là công ty tự bù lỗ, khoảng hơn 100 triệu đồng.
Bài học: Với dự án fixed-price, không bao giờ dùng mỗi expert judgment. Minh lẽ ra nên phân rã bằng WBS, liệt kê rõ compatibility matrix, rồi dùng PERT cho những phần mơ hồ. Quan trọng nhất: mọi giả định (chỉ test 1 trình duyệt, không test thanh toán…) phải được viết ra và khách hàng ký xác nhận. Assumption không được ghi lại chính là nơi ngân sách "bốc hơi".
Tình huống 2: Đội Agile dùng năng suất lịch sử để ước lượng sprint
Một startup fintech ở Hà Nội chạy Scrum, mỗi sprint 2 tuần. QA Lan không dùng person-days mà theo dõi velocity kiểm thử: trong 5 sprint gần nhất, đội test hoàn thành trung bình 45 test case thực thi và 8 bug retest mỗi ngày cho mỗi tester.
Đầu sprint mới, PO đưa 4 user story với tổng khoảng 180 test case ước tính. Lan tính nhanh: 180 / 45 ≈ 4 ngày thực thi, cộng thời gian thiết kế test case và buffer retest, ra khoảng 7 person-days. Với 2 tester, gói gọn trong sprint. Lan cũng cảnh báo PO rằng một story có tích hợp bên thứ ba (cổng thanh toán) nên được dùng hệ số phức tạp Complex, đội thêm 1.5 ngày buffer.
Bài học: Ước lượng dựa trên dữ liệu lịch sử (velocity) chính xác hơn nhiều so với cảm tính, và càng chạy nhiều sprint càng chuẩn. Việc theo dõi năng suất thực tế biến ước lượng thành một quy trình cải tiến liên tục, không phải trò đoán mò.
Tình huống 3: Dùng PERT để bảo vệ deadline trước áp lực từ PM
Tại một dự án e-commerce ở Đà Nẵng, PM ép QA Hùng: "Sếp muốn test xong đợt sale trong 10 ngày". Hùng không cãi bằng cảm tính. Anh lấy từng hạng mục và áp PERT. Riêng module tính khuyến mãi (nhiều rule chồng nhau) có O = 4, M = 7, P = 16 ngày → E = 8 ngày. Tổng cả dự án ra 18 ngày, không thể ép xuống 10.
Hùng trình bảng ước lượng ba điểm cho PM, chỉ rõ module khuyến mãi là điểm rủi ro lớn nhất. Kết quả: PM đồng ý cắt phạm vi (chỉ test 3 loại khuyến mãi phổ biến nhất trong đợt đầu), kéo deadline còn 13 ngày và bổ sung 1 tester.
Bài học: Ước lượng có cấu trúc là công cụ đàm phán. Khi bạn có con số và giả định rõ ràng, cuộc tranh luận chuyển từ "cảm giác của bạn vs áp lực của sếp" sang "dữ liệu vs phạm vi" — một cuộc chơi công bằng hơn nhiều cho QA.
Hướng dẫn từng bước
Đây là quy trình 7 bước bạn có thể áp dụng ngay cho lần ước lượng tiếp theo:
- Làm rõ phạm vi (scope). Đọc kỹ yêu cầu, xác định cần test cái gì, loại test nào (chức năng, tương thích, hiệu năng…), và quan trọng là không test cái gì. Ghi lại toàn bộ giả định.
- Phân rã công việc bằng WBS. Chia thành các đầu việc: phân tích yêu cầu, thiết kế test case, review, chuẩn bị test data & môi trường, thực thi, báo cáo bug, retest & regression, viết test summary report.
- Chọn kỹ thuật ước lượng phù hợp. Phạm vi rõ và có dữ liệu lịch sử → dùng năng suất test case. Phạm vi mơ hồ → dùng PERT ba điểm. Giai đoạn rất sớm → expert judgment / analogous để cho con số thô ban đầu.
- Ước lượng từng đầu việc con bằng kỹ thuật đã chọn, ra person-hours hoặc person-days.
- Cộng thêm overhead và buffer. Thêm 15–25% cho họp/giao tiếp/báo cáo và 10–20% buffer rủi ro. Ghi rõ đâu là con số thuần, đâu là con số đã cộng buffer.
- Chuyển đổi effort sang duration. Chia tổng effort cho số tester khả dụng và năng suất hiệu quả thực (khoảng 6 giờ/ngày, không phải 8), để ra số ngày lịch.
- Trình bày kèm giả định và rủi ro. Đừng đưa một con số trần trụi. Hãy trình bày dạng khoảng ("18–20 ngày"), liệt kê giả định và nêu rõ hạng mục rủi ro cao nhất. Đây là điểm khiến PM tin tưởng bạn.
Lỗi thường gặp & mẹo
Lỗi thường gặp:
- Quên các hoạt động "ẩn". Nhiều người chỉ ước lượng thời gian thực thi test, quên setup môi trường, chuẩn bị test data, retest sau khi dev fix, và regression. Retest thường ngốn 20–30% công sức của cả chu kỳ.
- Nhầm effort với duration. Nói "40 ngày" mà không nói rõ là 40 người-ngày, khiến PM lập kế hoạch sai.
- Ước lượng theo áp lực, không theo dữ liệu. Đưa con số PM muốn nghe thay vì con số thực tế — đây là cách nhanh nhất để dự án trễ và bạn bị đổ lỗi.
- Giả định năng suất 100%. Không ai làm việc hiệu quả trọn 8 tiếng. Ước lượng dựa trên 8 giờ luôn thiếu.
- Không ghi lại giả định. Khi phát sinh, bạn không có cơ sở để nói "cái này ngoài phạm vi đã thống nhất".
- Ghi lại số liệu thực tế (actual) sau mỗi dự án và so với ước lượng ban đầu. Đây là kho báu giúp lần sau bạn ước lượng chính xác hơn. Không có dữ liệu lịch sử thì mọi kỹ thuật đều chỉ là đoán.
- Luôn ước lượng theo khoảng, không theo điểm. "18–20 ngày" trung thực và chuyên nghiệp hơn "19 ngày".
- Ước lượng cùng team, không một mình. Kỹ thuật Planning Poker (mỗi người bốc số độc lập rồi thảo luận điểm lệch) giúp lộ ra rủi ro ẩn mà một người dễ bỏ sót.
- Tách riêng con số thuần và buffer khi trình bày, để PM thấy bạn minh bạch chứ không "thổi phồng".
- Ước lượng lại (re-estimate) khi phạm vi thay đổi. Ước lượng không phải bản khắc đá — cập nhật nó khi có thông tin mới là điều chuyên nghiệp.
Bài tập thực hành
Bài 1 — PERT cơ bản: Bạn cần test module giỏ hàng. Optimistic = 4 ngày, Most likely = 6 ngày, Pessimistic = 14 ngày. Tính ước lượng PERT. (Đáp án: E = (4 + 24 + 14)/6 = 7 ngày.)
Bài 2 — Effort vs Duration: Một module cần tổng 60 person-hours. Đội có 2 tester làm song song, năng suất hiệu quả 6 giờ/ngày. Tính số ngày lịch cần hoàn thành. (Gợi ý: 60 / (2 × 6) = 5 ngày lịch.)
Bài 3 — WBS thực tế: Chọn một tính năng bạn quen thuộc (ví dụ chức năng đăng nhập có OTP). Hãy phân rã thành ít nhất 6 đầu việc con, ước lượng thời gian từng việc, cộng 20% overhead và 15% buffer, ra con số cuối cùng. Ghi rõ 3 giả định bạn đã đặt ra.
Bài 4 — Đàm phán: Giả sử ước lượng của bạn cho một đợt release là 15 ngày, nhưng PM chỉ có 9 ngày. Hãy viết 3 phương án bạn sẽ đề xuất (ví dụ: cắt phạm vi test phần nào, thêm bao nhiêu tester, những rủi ro gì nếu ép deadline). Đây là bài tập luyện kỹ năng dùng ước lượng để đàm phán.
Tóm tắt
Ước lượng kiểm thử là kỹ năng biến "cảm giác" thành con số có căn cứ — nền tảng để bạn cam kết deadline, đàm phán nguồn lực và lập ngân sách. Bốn kỹ thuật cốt lõi bạn cần nắm là: WBS (phân rã công việc), ước lượng theo năng suất test case (dựa dữ liệu lịch sử), PERT ba điểm (xử lý sự không chắc chắn với công thức E = (O + 4M + P)/6), và expert judgment / analogous (dùng kinh nghiệm và dự án tương tự).
Dù chọn kỹ thuật nào, đừng quên cộng overhead và buffer, phân biệt rõ effort với duration, ghi lại mọi giả định, và trình bày ước lượng theo khoảng kèm rủi ro. Quan trọng nhất: hãy lưu lại số liệu thực tế sau mỗi dự án — vì mỗi lần ước lượng chính là dữ liệu huấn luyện cho lần ước lượng tiếp theo. Một QA ước lượng giỏi không phải người đoán đúng nhờ may mắn, mà là người biến quá trình ước lượng thành một vòng lặp cải tiến liên tục.