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.
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:
Ươ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.
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.
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ả.
Phần dưới mình sẽ đi sâu hơn vào từng phương pháp nhé ^^
ý 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:
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á.
Flow thực hiện như sau:
| Mức độ | Trọng số (weightage) | |
|---|---|---|
| Complex (phức tạp) | 5 | |
| Medium (trung bình) | 3 | |
| Simple (đơn giản) | 1 |
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):
| STT | Function | Description | Point |
|---|---|---|---|
| 1 | Sign up | User can create new account | 1 |
| 2 | Login | User can login and access the app | 1 |
| 3 | Reset password | User can reset their password | 1 |
| 4 | Book an order | User book an order with desired vehicle | 5 |
| 5 | History | User can view detail their orders | 3 |
| 4 | Payment | User payment free by creadit card | 5 |
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:
| Trọng lượng | Số lượng point | Total | |
|---|---|---|---|
| Complex | 5 | 8 | 40 |
| Medium | 3 | 5 | 15 |
| Simple | 1 | 10 | 10 |
Như vậy, Total Function point = 40+15+10 = 65 Estimate man-hour per point = 3 Total Estimate Effort = 3*65 = 195 (man-hour)
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:
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:
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.
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.
Nguồn: https://viblo.asia/p/software-test-estimation-bat-buoc-tester-can-biet-07LKXw0r5V4
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
