10. Ước lượng thời gian hoàn thành

Cách ước lượng thời gian hoàn thành

Để ước lượng thời gian hoàn thành từng test case sao cho hiệu quả và chính xác, bạn có thể làm theo các bước sau dựa trên kinh nghiệm thực tế và cách tiếp cận có hệ thống:

1. Phân tích yêu cầu của test case:

   • Đọc kỹ yêu cầu (requirements) hoặc kịch bản thử nghiệm để hiểu rõ phạm vi công việc.
   • Xác định mức độ phức tạp: Test case đơn giản (ví dụ: kiểm tra giao diện) thường mất ít thời gian hơn so với test case phức tạp (ví dụ: kiểm tra tích hợp hệ thống hoặc xử lý dữ liệu lớn).

2. Đánh giá các yếu tố ảnh hưởng:

   • Mức độ quen thuộc: Nếu bạn đã quen với hệ thống hoặc chức năng cần test, thời gian sẽ ngắn hơn. Ngược lại, nếu là hệ thống mới, cần thêm thời gian để nghiên cứu.
   • Dữ liệu thử nghiệm: Việc chuẩn bị dữ liệu (data setup) có thể chiếm nhiều thời gian, đặc biệt nếu cần tạo dữ liệu phức tạp hoặc phụ thuộc vào bên thứ ba.
   • Công cụ hỗ trợ: Sử dụng automation testing sẽ nhanh hơn manual testing, nhưng cần tính thêm thời gian viết script nếu chưa có sẵn.

3. Ước lượng thời gian cụ thể:

   • Test case đơn giản: 15-30 phút (ví dụ: kiểm tra một trường nhập liệu).
   • Test case trung bình: 1-2 giờ (ví dụ: kiểm tra luồng đăng nhập với nhiều điều kiện).
   • Test case phức tạp: 3-6 giờ hoặc hơn (ví dụ: kiểm tra giao dịch end-to-end hoặc xử lý lỗi hệ thống).
   • Thêm 20-30% thời gian dự phòng để xử lý các vấn đề phát sinh như lỗi hệ thống, tài liệu không rõ ràng, hoặc cần trao đổi với team.

4. Phân bổ thời gian hợp lý:

   • Chia nhỏ công việc: Ví dụ, 30% thời gian cho việc chuẩn bị (setup môi trường, dữ liệu), 50% cho thực thi test, 20% cho ghi nhận kết quả và báo cáo lỗi.
   • Nếu làm việc nhóm, tính thêm thời gian phối hợp giữa các thành viên.

5. Kiểm tra và điều chỉnh:

   • Sau khi hoàn thành vài test case, so sánh thời gian thực tế với ước lượng ban đầu. Nếu có sai lệch lớn, điều chỉnh cách tính cho các test case tiếp theo.
   • Dùng kinh nghiệm từ dự án trước để cải thiện độ chính xác.

Ví dụ thực tế:

• Test case kiểm tra nút “Đăng nhập” với 3 bộ dữ liệu (hợp lệ, không hợp lệ, trống):
  • Chuẩn bị: 15 phút.
  • Thực thi: 30 phút.
  • Báo cáo: 15 phút.
  • Tổng: ~1 giờ (cộng thêm 15 phút dự phòng nếu cần).

Hiệu quả không chỉ đến từ tốc độ mà còn từ việc đảm bảo test case bao quát hết các trường hợp và phát hiện lỗi quan trọng.

PERT (Program Evaluation and Review Technique)

• Định nghĩa: PERT là phương pháp ước lượng thời gian dựa trên xác suất, sử dụng ba kịch bản:
  • O: lạc quan (Optimistic),
  • M: khả thi nhất (Most likely),
  • P: bi quan (Pessimistic).

để tính toán thời gian trung bình có trọng số.

• Công thức:
  

• Đặc điểm chính:

  • Tập trung vào sự không chắc chắn (uncertainty) và rủi ro.
  • Phù hợp với các dự án có nhiều biến số khó dự đoán trước, như kiểm thử phần mềm khi môi trường thay đổi liên tục.
  • Không yêu cầu thứ tự thực hiện các nhiệm vụ (tasks) mà chỉ cần ước lượng thời gian cho từng công việc riêng lẻ.

Ví dụ về PERT trong Kiểm thử Phần mềm

Giả sử bạn đang lập kế hoạch kiểm thử cho một tính năng "Xác thực người dùng" trong một ứng dụng web. Tính năng này bao gồm 3 test case chính:

1. Test case A: Kiểm tra đăng nhập với dữ liệu hợp lệ.
2. Test case B: Kiểm tra đăng nhập với dữ liệu không hợp lệ.
3. Test case C: Kiểm tra tích hợp API xác thực với hệ thống backend.

Chúng ta sẽ sử dụng PERT để ước lượng thời gian hoàn thành cho từng test case dựa trên 3 giá trị: O (Optimistic), M (Most Likely), và P (Pessimistic). Công thức PERT là:

Ước lượng từng test case

Test case A: Đăng nhập với dữ liệu hợp lệ

• O (Lạc quan): 0.5 giờ (mọi thứ trơn tru, không lỗi).
• M (Khả thi nhất): 1 giờ (dựa trên kinh nghiệm, có thể mất chút thời gian chuẩn bị).
• P (Bi quan): 2 giờ (hệ thống lỗi hoặc cần debug).

Tính thời gian ước lượng:

Test case B: Đăng nhập với dữ liệu không hợp lệ

• O: 0.75 giờ.
• M: 1.5 giờ.
• P: 3 giờ.

Test case C: Tích hợp API xác thực

• O: 2 giờ.
• M: 4 giờ.
• P: 8 giờ (API gặp vấn đề, cần phối hợp với team backend).

Tổng thời gian dự kiến

Tổng thời gian để kiểm thử tính năng "Xác thực người dùng" là:

Vậy, bạn cần khoảng 7 giờ để hoàn thành kiểm thử, với giả định các test case được thực hiện độc lập.

Đánh giá độ lệch (nếu cần)

Để biết mức độ không chắc chắn, ta tính độ lệch chuẩn (SD) cho Test case C (phức tạp nhất):

Khoảng thời gian dao động: , tức là từ 3.33 đến 5.33 giờ.

Dưới đây là một ví dụ cụ thể về cách áp dụng PERT (Program Evaluation and Review Technique) để ước lượng thời gian trong một tình huống thực tế, được trình bày dưới dạng Markdown có thể sử dụng trong Docusaurus với rehype-mathjax. Tôi sẽ mô tả một kịch bản kiểm thử phần mềm và tính toán minh họa.

---

Giải thích ví dụ

1. Kịch bản: Đây là một tình huống kiểm thử phần mềm thực tế, nơi bạn phải ước lượng thời gian cho các test case với độ không chắc chắn (hệ thống mới, phụ thuộc vào API, v.v.).
2. Tính toán: Mỗi test case được áp dụng công thức PERT để đưa ra thời gian trung bình có trọng số.
3. Kết quả: Tổng thời gian (~7 giờ) là con số hợp lý để lập kế hoạch, cộng thêm thời gian dự phòng nếu cần.
4. Độ lệch: Được tính cho test case phức tạp nhất để đánh giá rủi ro.

---