Bài viết này mình vừa tìm hiểu vừa viết lại hiểu biết của mình, mình áp dụng được các kiến thức này trong project hiện tại. Hi vọng các thông tin trong bài viết sẽ giúp tester định hướng công việc cần làm và ước lượng thời gian hoàn thành công việc sát nhất thực tế ^^. Sở dĩ mình tìm hiểu phần này vì mình không thích nghe cách estimate dựa trên "kinh nghiệm" cho lắm, mình hỏi khá nhiều người về việc ước lượng thời gian cho tasks, thì mọi người hay trả lời kiểu "test lead estimte rồi, kinh nghiệm, bla blo", mình muốn ướng lượng dựa trên kỹ thuật/ phương pháp, con số,... đại loại là cái xác đáng hơn.

Đối với tester chưa có nhiều kinh nghiệm (junior) thì hay sợ khi nhắc đến estimate, vì họ không biết phải bắt đầu từ đâu. Bản thân mình ngày trước cũng vậy, mình khá sợ họp vì mỗi lần họp anh leader đọc tên 1 task + mô tả trong task và hỏi mình test trong bao lâu. Thực sự lúc đấy đầu mình trống rỗng, mình không biết estimate như thế nào, để thoát khỏi nỗi sợ đó thì mình tìm hiểu dần dần và làm dần dần.

Ước lượng ... gì?

Thông thường, mọi người sẽ hay ước lượng human resource (nguồn lực con người) và thời gian, thường tính trên đơn vị man-hour. Tuy nhiên, đầy đủ của estimate gồm:

• Resource: bao gồm con người, thiết bị, cơ sở vật chất, kinh phí để hoàn thành công việc
• Time: thời gian thực hiện cho đến thời hạn bàn giao (deadline delivery)
• Human skill: các kỹ năng con người, bao gồm kiến thức, kinh nghiệm,..
• Cost: chi phí thực hiện

Ươc lượng phỏng đoán thực tế sẽ diễn ra như thế nào, giúp tránh vượt quá thời gian cho phép, vượt quá các vấn đề về tài chính. Mục tiêu của ướng lượng là càng sát thực tế càng tốt.

Mình sẽ làm những gì?

Ví dụ như để test một hệ thống thương mại điện tử như http://store.demoqa.com/ , mình sẽ cố gắng phân tách từng thành phần nhỏ nhất có thể, nhỏ đến khi mình biết là thành phần test đó cần test các trường hợp (case) như thế nào.

Ví dụ:

Đối với mỗi mục nhỏ như trên, mình tính số lượng test case dự kiến tương ứng, và tính tổng số cho functions và toàn dự án. Dựa trên số test case đó, mình dựa trên năng suất (productivity) của nhân lực hiện tại (ví dụ phục trách dự án có 2QA) và dựa trên mức độ khó của function để đưa ra số effort cần thiết cho việc test toàn bộ dự án. Trong trường hợp ví dụ này thì mình cần ít nhất 5 ngày để test xong function chính.

Các phương pháp ước lượng kiểm thử

Mình kể tên được 8 phương pháp, trong đó 4 phương pháp đầu được sử dụng rộng rãi và phổ biến hơn cả.

1. Work Breakdown Structure
2. Function Point/Testing Point Analysis
3. 3-Point Software Testing Estimation Technique
4. Experience-based testing estimation technique
5. Wideband Delphi technique
6. Use – Case Point Method
7. Percentage distribution
8. Ad-hoc method

Phần dưới mình sẽ đi sâu hơn vào từng phương pháp nhé ^^

1. Work breakdown structure (WBS)

ý tưởng của WBS chính là cái mình đã đề cập ở trên: "chia để trị". Chia cả project to thành các module, chia module thành các function nhỏ hơn, sub-module,..., chia task lớn thành các task nhỏ hơn. Ví dụ mình có task: Testing for version 2.5, vậy thì có thể có các task nhỏ sau:

2. Function Point Method

Trong phương pháp này, mình sẽ ước lượng: size (kích thước), duration (thời lượng) và cost (chi phí). Point ở đây mình hiểu như đơn vị để đánh giá.

• Size: phụ thuộc vào kích thước của function. Kích thước của function được phản ánh qua số lượng các công việc mà function đó thực hiện, function nào càng thực hiện nhiều công việc, function đó càng phức tạp, size càng lớn.
• Duration: tổng số thời gian cần thiết (man-hour)
• Cost: tổng chi phí = duration * cost 1 point

Flow thực hiện như sau:

1. Định nghĩa các mức độ của function

2. Đánh giá mức độ cho từng function tương ứng
3. Ươc lượng trên 1 point
4. Ươc lượng toàn bộ công việc

Ví dụ như mình đang test một hệ thống đặt taxi giống Uber, mình sẽ tạo 1 danh sách chức năng sau (bước 2 như flow):

Tiếp đến, mình ướng lượng trên 1 point, giả sử function Sign up (tương ứng 1 point) có 80 test cases, thời gian đểkiểm thử xong ước chừng 3h, vậy mình sẽ đặt giá trị 1 point = 3 man-hour. Bước cuối cùng, mình sẽ tính trên toàn bộ các task:

Như vậy, Total Function point = 40+15+10 = 65 Estimate man-hour per point = 3 Total Estimate Effort = 3*65 = 195 (man-hour)

3. Three Point Estimation

Phương pháp Functional Point đã tính toán ra số man-hour để hoàn thành công việc, nhưng lưu ý đó là trong điều kiện không có sự cố hoặc điều kiện phát sinh. Tuy nhiên, trong quá trình làm thực sự thì dự án sẽ đối mặt với một vài vấn đề ví dụ như nhân sự xin nghỉ, máy móc hỏng, đường truyền internet bị gián đoạn,... Để estimate chuẩn hơn, Three Point Estimation đưa ra 3 trường hợp ước lượng:

• Best-case estimate (A): đội dự án gồm các thành viên giỏi, có thể hoàn thành công việc trong thời gian ngắn nhất có thể
• Most likely case estimate (M): Trường hợp điều kiện hiện tại, sẽ không có gì thay đổi trong suốt quá trình chạy dự án
• Worst case estimate (B): đội gồm các thành viên có năng suất không cao, điều kiện không đảm bảo

Công thức tính: Total Estimate Effort (TEE) = (A+4*M+B)/6

Vẫn ví dụ app đặt taxi ở trên, ta ước lượng số effort trong 3 trường hợp:

• Best-case, A = 160 (man-hour)
• Most likely case, B = 195 (man-hour)
• Worst case, C = 150 (man-hour) Suy ra, TEE = (160+ 4*195+150)/6 = 182 (man-hour)

4. Wideband Delphi Technique

Phương pháp này phù hợp cho đội dự án từ 3-7 người. Kết quả estimate cuối cùng sẽ được chọn dựa trên sự nhất trí của mọi người trong đội, Wideband cũng được dùng phổ biến trong phát triển phần mềm, kèm theo việc lên kế hoạch theo bộ bài (planning poker)

Ngay từ vòng đầu, mỗi người trong team có quan điểm ước lượng khác nhau, do đó kí hiệu X nằm xa nhau, sau đó, trải qua các vòng, trong mỗi vòng thì mọi người cùng giải thích quan điểm để cuối cùng đưa về một quan điểm chung. Ví dụ như trong hình thì đến vòng 3, số man-hour xê dịch quan điểm 2000. Như vậy, cả đội sẽ estimate cho task đó là 2000 man-hour.

5. Experienced-based Technique

Experience-based chủ yếu dựa trên kinh nghiệm và dữ liệu thu thập từ các dự án tương tự, các vòng phát triển trước của sản phẩm. Tuy nhiên cách này phụ thuộc nhiều vào quan điểm cá nhân và không có lợi cho người mới bắt đầu. Các dự án thường khác nhau về nghiệp vụ, tính chất, vv.. nên estimate dựa trên kinh nghiệm dễ "vênh" so với thực tế. Bản thân mình luôn khuyến khích mọi người dùng 4 phương pháp đầu kể trên.

Trên đây là một số kiến thức mình vừa tìm, vừa hiểu, vừa làm, mong sẽ giúp ích cho các bạn, đặc biệt là những bạn junior chưa ước lượng được thời gian làm việc.

Tham khảo

https://viblo.asia/p/ki-thuat-estimate-trong-kiem-thu-pham-mem-maGK7Epxlj2 https://www.slideshare.net/nworah/test-estimation-techniques https://www.linkedin.com/pulse/effort-estimation-model-software-testing-rahul-kumar/