Kỹ thuật ước lượng - Estimation Techniques

Ước tính những nỗ lực cần thiết cho yêu cầu kiểm thử là một trong những nhiệm vụ chủ yếu và quan trọng trong SDLC (Software Development Life Cycle). Việc estimate chính xác trong kiểm thử phần mềm giúp mức bao phủ sẽ là tối đa.

Theo tài liệu ISTQB thì có một số phương pháp estimate cơ như sau:

1. Metrics-based approach: cách estimate này dựa vào các thông số thật của những chức năng hoặc dự án tương tự trong quá khứ.
2. Expert-based approach: việc thực hiện estimate này dựa vào kinh nghiệm cá nhân của người thực hiện estimate về lĩnh vực này.
3. Test Case Point Estimation: dựa vào thời gian thực hiện (execute) test case để ước lượng thời gian test cho chức năng nào đó hoặc cho một dự án.

Ngoài ra sẽ có một số phương pháp estimate khác sẽ được đề cập trong bài viết này. Một số ký thuật có thể hữu ích trong việc estimate những nỗ lực cần thiết cho công việc kiểm thử.

Nỗ lực kiểm thử (Effort Testing) không dựa trên bất kỳ khung thời gian nào. Những nỗ lực đó tiếp tục cho đến thời điểm trước khi quyết định được thiết lập, không phụ thuộc vào việc hoàn thành các kiểm thử.

Điều này chủ yếu là do thực tế đã được quy ước, ước lượng nỗ lực kiểm thử là một phần của dự toán phát triển. Chỉ trong trường hợp các kỹ thuật ước lượng sử dụng WBS (Work Breakdown Structure), như Wideband Delphi, Three-point Estimation, PERT, and WBS, bạn có thể thu được các giá trị từ hoạt động ước tính của hoạt động kiểm thử.

Nếu bạn đã có được ước tính như điểm chức năng (Funtion Point), sau đó theo Caper Jones,

Số lượng Test case = (Số điểm chức năng) × 1.2

Một khi bạn có số lượng test case, bạn có thể có dữ liệu về productivity từ cơ sở dữ liệu của tổ chức và đạt được các nỗ lực cần thiết để thử nghiệm.

Phương pháp tỷ lệ phần trăm nỗ lực phát triển

Nỗ lực kiểm thử cần thiết là làm theo tỉ lệ trực tiếp hoặc tỷ lệ phần trăm của các nỗ lực phát triển. Nỗ lực phát triển có thể được ước tính bằng việc sử dụng Line of code (LOC) hoặc điểm chức năng (FP). Sau đó, tỷ lệ phần trăm của những nỗ lực để kiểm thử được lấy từ cơ sở dữ liệu của tổ chức. Tỷ lệ phần trăm thu được sẽ được sử dụng để đưa ra ước tính nỗ lực cho hoạt động kiểm thử.

Tính toán dự án kiểm thử

Một vài tổ chức hiện đang cung cấp độc lập dịch vụ xác minh (verification) và xác nhận (validation) cho các khách hàng của họ và điều đó sẽ có nghĩa là toàn bộ các hoạt động của dự án sẽ là kiểm thử. Ước tính các dự án thử nghiệm đòi hỏi kinh nghiệm về các dự án đa dạng cho các chu kỳ phần mềm thử nghiệm cuộc sống. Khi bạn đang ước tính một dự án kiêm thử thì cần phải cân nhắc đến các vấn đề sau:

• Kỹ năng đội nhóm
• Kiến thức về domain mà dự án sẽ làm
• Độ phức tạp của các ứng dụng
• Dữ liệu lịch sử
• Chu kỳ lỗi cho dự án
• Tài nguyên sẵn có
• Mức độ thay đổi về năng suất làm việc
• Môi trường hệ thống và thời gian chết

Kỹ thuật Estimation Testing

Việc kiểm tra kỹ thuật ước lượng sau đây được chứng minh là chính xác và được sử dụng rộng rãi:

• PERT kỹ thuật ước lượng kiểm thử phần mềm
• UCP (Use-Case Point) phương pháp
• WBS
• Kỹ thuật Wideband Delphi
• Chức năng điểm/thử nghiệm phân tích điểm
• Tỷ lệ phần trăm phân phối
• kỹ thuật dự toán thử nghiệm dựa trên kinh nghiệm

**1. PERT kỹ thuật ước lượng kiểm thử phần mềm **

PERT dựa trên phương pháp thống kê trong đó mỗi testing task được chia thành các nhiệm vụ và sau đó ba loại dự toán được thực hiện trên mỗi sub-task.

Các công thức được sử dụng bởi kỹ thuật này là:

Kiểm tra Ước tính (Test Estimate) = (O + (4 × M) + E) / 6

Trong đó:

O = ước tính lạc quan/Case tốt nhất (trường hợp tốt nhất, trong đó không có gì sai và tất cả các điều kiện là tối ưu).

M = Nhiều khả năng ước tính/Case bình thường (có thể có một số vấn đề nhưng hầu hết những điều này sẽ đi đúng).

E = ước tính bi quan/Case xấu nhất (trường hợp kịch bản xấu nhất mà tất cả mọi thứ đi sai).

Độ lệch chuẩn cho kỹ thuật này được tính như sau

Độ lệch chuẩn (Standard Deviation) = (E - O) / 6

2. Use-Case Point Method

UCP dựa trên các trường hợp sử dụng mà tính toán trọng số Actors không điều chỉnh và không điều chỉnh trường hợp sử dụng trọng số để xác định dự toán kiểm thử phần mềm.

Use-case là một tài liệu trong đó quy định mức độ khác nhau về người sử dụng, hệ thống hoặc các bên liên quan khác tương tác với các ứng dụng liên quan. Chúng được đặt tên là "Actors". Các tương tác này thực hiện một số mục tiêu được xác định để bảo vệ quyền lợi của các bên liên quan thông qua hành vi hoặc luồng khác nhau được gọi là kịch bản (scenarios).

Bước 1 - Đếm số lượng Actor. Actors này bao gồm tích cực, tiêu cực và ngoại lệ.

Bước 2 - Tính toán trọng số những actors không được điều chỉnh (Unadjusted Actor Weights) như:

UAW (Unadjusted Actor Weights) = Tổng số các Actors

Bước 3 - Đếm số lượng các Use-case.

Bước 4 - Tính toán trọng số Use-Case không được điều chỉnh (Unadjusted Use-Case Weights ) như sau:

Unadjusted Use-Case Weights (UUCW) = Tổng số Use-Case

Bước 5 - Tính toán điểm Use-Case chưa được điều chỉnh (Unadjusted Use-Case Point) như sau:

Unadjusted Use-Case Point (UUCP) = (UAW + UUCW)

Bước 6 - Xác định yếu tố kỹ thuật / môi trường (TEF). Nếu không có sẵn, xem như nó như 0.50.

Bước 7 - Tính toán điều chỉnh Use-Case Point như

Adjusted Use-Case Point (AUCP) = UUCP × [0,65 + (0,01 × TEF]

Bước 8 - Tính tổng effort như sau:

Total Effort = AUCP × 2

3. Cấu trúc phân chia công việc

Bước 1 - Tạo WBS bằng cách phân chia dự án thử nghiệm thành miếng nhỏ.

Bước 2 – Chia các modules thành các sub-module

Bước 3 - Chia sub-module thành các chức năng.

Bước 4 – Chia chức năng chia thành các chức năng nhỏ hơn.

Bước 5 - Xem xét tất cả các yêu cầu kiểm tra để đảm bảo chúng được thêm vào trong WBS.

Bước 6 - Chỉ ra các task mà nhóm của bạn cần phải hoàn thành.

Bước 7 - Ước tính các nỗ lực cho từng task.

Bước 8 - Ước lượng thời gian của từng task.

4. Kỹ thuật Wideband Delphi

Trong phương pháp Wideband Delphi, WBS được phân phối cho một nhóm gồm 3-7 thành viên để estimate lại các task. Ước tính cuối cùng là kết quả cuối cùng của việc re-estimate của dự án là dựa trên sự đồng thuận của các thành viên trong nhóm.

Phương pháp này nói thêm về kinh nghiệm chứ không phải là bất kỳ công thức thống kê nào. Phương pháp này được phổ biến bởi Barry Boehm nhấn mạnh trên sự lặp lại nhóm để đạt được một sự đồng thuận, nơi các nhóm hình dung những khía cạnh khác nhau của vấn đề trong khi ước lượng nỗ lực kiểm thử.

5. Điểm chức năng (FP) / Testing Point Analysis (TPA)

FPS chỉ ra các chức năng của phần mềm ứng dụng từ quan điểm của người sử dụng và được sử dụng như là một kỹ thuật để ước tính kích thước của một dự án phần mềm.

Trong kiểm thử, việc dự toán được dựa trên tài liệu đặc tả yêu cầu, hoặc trên một ứng dụng mẫu được tạo trước đó. Để tính toán FP cho một dự án, một số thành phần chính được yêu cầu. Chúng là:

Điểm chức năng dữ liệu không được điều chỉnh (Unadjusted Data Function Points) - i) tập tin nội bộ, ii) Các giao diện bên ngoài

Điểm chức năng giao dịch chưa điều chỉnh (Unadjusted Transaction Function Points) - i) Đầu vào của người dùng, ii) Kết quả của người dung & iii) Yêu cầu của người dùng

Công thức cơ bản Capers Jones :

Number of Test Case = Number of Function Points × 1.2

Tổng số nỗ lực thực tế (Total Actual Effort) :

TAE = (Number of Test Case) x (Percentage of Development Effort / 100)

6. Tỷ lệ phần trăm phân phối

Trong kỹ thuật này, tất cả các giai đoạn của phát triển phần mềm (SDLC) được quy định effort = 0%. Điều này có thể được dựa trên dữ liệu của những dự án tương tự trong quá khứ. Ví dụ :

|_. Phase |_. % of Effort |
|Project Management|  7|
|Requirements|  9|
|Design|  16|
|Coding|  26|
|Testing (all Test Phases)|  27|
|Documentation|  9|
|Installation and Training|  6|

Tiếp theo,% effort để kiểm thử (tất cả các giai đoạn kiểm thử) được phân phối tiếp cho tất cả các kiểm thử:

|_. All Testing Phases |_. % of Effort |
|Component Testing|  16|
|Independent  Testing|  84|
|_. Total|_.100|
|_. Independent Testing|_. % of Effort|
|Integration Testing|  24|
|System Testing|  52|
|Acceptance Testing|  24|
|_. Total|_.100|
|_.System Testing|_. % of Effort|
|Functional System Testing|  65|
|Non-functional System Testing|  35|
|_. Total|_.100|
|Test Planning and Design Architecture|  50|
|Review phase|  50|

**7.	Kỹ thuật ước tính thử nghiệm dựa trên kinh nghiệm**

Kỹ thuật này được dựa trên sự tương tự và chuyên môn của người thực hiện estimate. Kỹ thuật này giả định rằng bạn đã thử nghiệm các ứng dụng tương tự  trong các dự án trước đó và thu thập các số liệu từ các dự án này. Bạn cũng thu thập số liệu từ các thử nghiệm trước đây. Tiếp nhận  đầu vào này bạn có thể estimate được effort dành cho testing.

Kết luận: Theo ý kiến cá nhân mình, khi thực hiện estimate cho một chức năng hoặc một dự án nào đó, tốt nhất nên kết hợp các phương pháp trên lại với nhau để cho ra kết quả tốt nhất (gần đúng nhất). Ngoài ra, còn phải quan tâm đến một số tiêu chí sau để estimate tốt hơn:

+ Các đặc tính, tính chất riêng biệt của từng sản phẩm phần mềm/ dự án/ chức năng: Chất lượng tài liệu (requirement, specificaiton,...), tính phức tạp, độ lớn và một số yêu cầu về security, performance và tài liệu yêu cầu khác (ví dụ yêu cầu test procedure, viết test cases hay không)

+ Dựa vào qui trình phát triển phần mềm hiện tại của tổ chức: mức độ trưởng thành của nhóm test và nhóm phát triển phần mềm và của tổ chức, qui trình test, các tool đang áp dụng (tool quản lý test và hỗ trợ test và **tool quản lý bug**,...), kỹ năng của những cá nhân tham gia vào dự án, và thời gian cho phép để phát triển dự án (áp lực thời gian)...

+ Dựa vào một số thông tin về dự án trước: số lượng bug của lần release trước (hoặc của dự án trước), số lượng test case hoặc công việc phải update lại (ví dụ, sau khi review test case, thì trung bình mỗi Tester phải update lại bao nhieu test case - rework),...

Tài liệu dịch: https://www.tutorialspoint.com/estimation_techniques/estimation_techniques_testing.htm