Mô hình ước tính thời gian kiểm thử cho một dự án

Để thành công trong việc ước tính, dự án kiểm thử phần mềm và thực hiện đúng quan trọng như chu trình phát triển phần mềm vậy. Kỹ thuật ước tính kiểm thử phần mềm đóng một vai trò rất quan trọng trong việc tạo ra danh tiếng tốt với khách hàng trong khi đấu thầu dự án để kiểm thử.

Một trong những yếu tố quan trọng nhất trong khi ước tính công sức kiểm thử là kinh nghiệm về các dự án đa dạng cho chu kỳ kiểm thử phần mềm. Rõ ràng không thể áp đặt số ngày cho bất kỳ nhiệm vụ nào hoặc lấy công thức thời gian cũ là một phần ba của effort phát triển được. Đây là một trong những kỹ thuật ước tính được sử dụng rộng rãi nhất bởi các công ty cung cấp dịch vụ kiểm thử phần mềm. Thực tế là phương pháp này không dựa trên bất kỳ nguyên lý khoa học hoặc kỹ thuật nào cả.

Đối với bất kỳ kỹ thuật ước lượng kiểm thử phần mềm nào, bạn nên đánh giá các yếu tố sau:

• Kiến thức miền và các yêu cầu cốt lõi
• Rủi ro và sự phức tạp của ứng dụng
• Kiến thức nhóm về chủ đề / kỹ năng
• Dữ liệu lịch sử cho dự toán trước đó để cải tiến và chính xác
• Ước tính nên bao gồm thời gian đệm
• Các chu kỳ lỗi cho dự án
• Nguồn lực sẵn có (Giống như kỳ nghỉ, ngày nghỉ, ngày nghỉ ốm có thể có ảnh hưởng lớn đến ước tính của bạn)

Những năm gần đây có rất nhiều kĩ thuật được phát triển để ước tính kiểm thử phần mềm. Ví dụ như:

• 3-Point Software Testing Estimation Technique
• Use-Case Point Method

Kỹ thuật ước tính kiểm thử phần mềm 3-Point (3-Point Software Testing Estimation Technique)

3-Point Software Testing Estimation Technique dựa trên các phương pháp thống kê trong đó mỗi nhiệm vụ thử nghiệm được chia thành các nhiệm vụ phụ và sau đó là ba loại về ước tính được thực hiện trên mỗi nhiệm vụ. Công thức sử dụng cho kĩ thuật này là: Test Estimate = P + (4N) + E / 6 Trong đó,

• P = Các kịch bản tích cực hoặc Ước tính lạc quan (Trường hợp tốt nhất mà không có gì sai và tất cả các điều kiện là tối ưu.)
• N = Kịch bản tiêu cực hoặc Ước tính có khả năng xảy ra nhiều nhất (Có thể có vấn đề nhưng hầu như mọi cái đều đi đúng hướng.)
• E = Các trường hợp ngoại lệ hoặc ước tính bi quan (Kịch bản cho trường hợp xấu nhất mà mọi thứ đều sai).

Độ lệch chuẩn cho kỹ thuật được tính như sau: Standard Deviation (SD) = (N – E)/6

Phương pháp Use – Case Point (Use – Case Point Method)

Phương pháp Use-Case Point được dựa trên use case, nơi mà ta tính toán trọng số un-adjusted actor và trọng số un-adjusted use case để quyết định ước tính kiểm thử phần mềm. Use case là một tài liệu đặc tả các người dùng, hệ thống hay các nhà thầu tương tác với ứng dụng liên quan. Chúng có tên là “Actors”. Các tương tác đạt được một số mục tiêu xác định nhằm bảo vệ lợi ích của tất cả các bên liên quan thông qua các hành vi hoặc luồng khác nhau được gọi là các kịch bản. Công thức sử dụng cho kĩ thuật này là:

• Tỉ trọng un-adjusted actor = tổng số các actors (tích cực, tiêu cực và đặc biệt)
• Tỉ trọng un-adjusted use case = tổng số các use cases
• Điểm un-adjusted use case = Tỉ trọng un-adjusted actor + Tỉ trọng un-adjusted use case
• Xác định các yếu tố kỹ thuật / môi trường (TEF) (nếu không có sẵn thì lấy là 0,50)
• Điểm adjusted use case = Điểm un-adjusted use case [0,65+ (0,01 TEF]
• Total Effort = Điểm adjusted use case 2

Các qui tắc ước tính

Bạn cần nhớ những qui tắc dưới đây khi thực hiện ước tính thời gian thực hiện kiểm thử cho 1 dự án

Qui tắc 1: Ước tính phải luôn dựa vào yêu cầu phần mềm

Tất cả các dự toán phải dựa trên những gì sẽ được kiểm tra, nghĩa là các yêu cầu về phần mềm. Thông thường, các yêu cầu phần mềm chỉ được thiết lập bởi nhóm phát triển mà không có hoặc chỉ một chút tham gia của nhóm thử nghiệm. Sau khi đã xác định được đặc điểm kỹ thuật, dự toán chi phí và thời gian, nhóm phát triển sẽ hỏi xem cần phải mất bao lâu để kiểm thử giải pháp. Câu trả lời nên được nói gần như ngay lập tức.

Sau đó, các yêu cầu phần mềm cũng sẽ được đọc và hiểu bởi nhóm kiểm tra. Nếu không có sự tham gia kiểm thử, có thể sẽ không có ước tính nghiêm túc nào được xem xét.

Qui tắc 2: Ước tính phải được dựa trên phán đoán chuyên môn

Trước khi ước tính, nhóm thử nghiệm phân loại các yêu cầu trong các loại sau: • Quan trọng: Nhóm phát triển ít có kiến thức về cách triển khai • Cao: Nhóm phát triển có kiến thức tốt về cách triển khai nhưng đây không phải là một nhiệm vụ dễ dàng • Bình thường: Nhóm phát triển có kiến thức tốt về cách thực hiện. Các chuyên gia trong mỗi yêu cầu nên nói phải mất bao lâu để kiểm thử chúng. Các loại trên sẽ giúp các chuyên gia trong việc ước lượng công sức để kiểm thử các yêu cầu.

Qui tắc 3: Ước tính luôn được dựa trên các dự án trước đó

Tất cả các dự tính nên được dựa trên kinh nghiệm/ hiểu biết từ các dự án trước đó. Nếu 1 dự án mới có yêu cầu giống với dự án trước đó, dụ tính sẽ được dựa trên dự án đó.

Qui tắc 4: Ước tính luôn dựa trên metrics (số liệu)

Nên tạo một OPD (Organization Process Database) để ghi lại số liệu của dự án.

Qui tắc 5: Ước tính không bao giờ quên quá khứ

Nhóm thử nghiệm tiếp tục sử dụng quy trình cũ và bảng tính. Sau khi ước tính được thực hiện theo các quy tắc mới, nhóm thử nghiệm ước tính lại bằng cách sử dụng quá trình cũ để so sánh cả hai kết quả. Thông thường, kết quả từ quá trình ước tính mới là rẻ hơn và nhanh hơn so với tỷ lệ cũ trong khoảng 20 đến 25%. Nếu nhóm thử nghiệm nhận được một tỷ lệ phần trăm khác nhau, đội thử nghiệm sẽ trở lại quy trình để hiểu nếu có điều gì đó bị bỏ qua.

Qui tắc 6: Ước tính phải được ghi lại

Tất cả các quyết định phải được ghi lại. Điều rất quan trọng bởi vì nếu các yêu cầu thay đổi vì bất kỳ lý do nào, hồ sơ sẽ giúp nhóm thử nghiệm ước tính lại. Nhóm thử nghiệm sẽ không cần phải trả lại tất cả các bước và đưa ra quyết định giống vậy. Đôi khi, đó là một cơ hội để điều chỉnh ước lượng được thực hiện trước đó.

Qui tắc 7: Ước tính phải được hỗ trợ bằng các công cụ

Một bảng tính chứa số liệu cần được tạo ra để giúp ước tính nhanh chóng. Bảng tính sẽ tính toán tự động các chi phí và thời gian cho mỗi giai đoạn thử nghiệm. Bản mẫu có thể chứa một số phần như: bảng chi phí, rủi ro và ghi chú miễn phí để được điền. Công cụ này có thể hiển thị các tùy chọn khác nhau để kiểm tra , giúp khách hàng quyết định kiểm thử nào anh ta cần.

Qui tắc 8: Ước tính luôn được xác nhận

Tất cả các dự toán cần được xác minh. Cần tạo một bảng tính khác để ghi lại ước lượng. Ước tính được so sánh với các ước tính trước được ghi lại trong một bảng tính để xem chúng có xu hướng tương tự hay không. Nếu dự tính có bất kỳ sai lệch nào từ những số liệu đã ghi, thì phải lập lại dự tính.

Qui tắc 9: Ước tính nên bao hàm được các yêu tố rủi ro

Dự tính nên bao hàm được tất cả các loại rủi ro như sự sẵn có của tài nguyên, thời gian sản phẩm đi xuống, cải tiến kỹ năng, khả năng học tập ...

Kịch bản:

Giả sử bạn có một dự án và bạn ước tính sẽ mất khoảng 300 ngày cho đội 10 người để hoàn thành. (3000 ngày làm việc – kịch bản Sunny day) Cần nhớ rằng 1 năm có 365 ngày làm việc (52 tuần x 5 ngày), không có ngày lễ. Nghĩa là dự án này sẽ cần 1.13 năm hay 13.6 tháng để hoàn thành. Giả sử 1 năm trung bình có 12 ngày nghỉ lễ ở công ty (tổng ảnh hưởng = 12x10 người = 120 ngày x 1.13 năm = 136 ngày) Cũng giả sử 1 nhân viên trung bình nghỉ ốm 4 ngày và 3 ngày nghỉ phép (tổng ảnh hưởng = 7 x 10 người = 70x 1.13 = 79) Cũng giả sử 1 nhân viên mất 3 ngày mỗi năm cho việc đào tạo (30 ngày) Tổng thời gian thay đổi do nhân viên nghỉ lễ, nghỉ ốm, nghỉ phép và đào tạo = 136+79+79+30=324 Như vậy, tổng ngày làm việc của dự án bây giờ sẽ = 3000+324 = 3324 hay tăng 10.8% (lịch 300 ngày bây giờ sẽ là 333 ngày hoặc 15.1 tháng)

Nguồn tham khảo https://www.linkedin.com/pulse/effort-estimation-model-software-testing-rahul-kumar