ISTQB – Chương 5 – Mục 5.2- Kế hoạch, ước lượng và chiến lược kiểm thử – Phần 4/6

KỸ THUẬT ƯỚC LƯỢNG

Có hai kỹ thuật ước lượng được đề cập trong Syllabus ISTQB. Một liên quan đến việc tham khảo ý kiến của những người sẽ thực hiện công việc và những người khác có chuyên môn về các nhiệm vụ sẽ được thực hiện. Cách khác liên quan đến việc phân tích các số liệu từ các dự án trước đây và từ dữ liệu ngành. Chúng ta hãy lần lượt xem xét từng cái.

Yêu cầu những người đóng góp cá nhân và các chuyên gia liên quan đến việc làm việc với các nhân viên có kinh nghiệm để phát triển cấu trúc phân chia công việc cho dự án. Sau khi hoàn thành, bạn sẽ làm việc cùng nhau để hiểu rõ nỗ lực, thời lượng, phụ thuộc và yêu cầu tài nguyên đối với từng nhiệm vụ.

Ý tưởng là sử dụng trí tuệ tập thể của nhóm để tạo ước tính cho việc kiểm thử. Khi sử dụng một công cụ như Microsoft Project hoặc bảng trắng (whiteboard) và ghi chú dán (sticky-notes), bạn và nhóm có thể dự đoán ngày kết thúc việc kiểm thử và các mốc quan trọng. Kỹ thuật này thường được gọi là ước lượng “từ dưới lên” (bottom up) vì bạn bắt đầu ở mức thấp nhất của phân tích theo thứ bậc trong cấu trúc phân chia công việc (nhiệm vụ) và để thời lượng, nỗ lực, phụ thuộc và tài nguyên cho mỗi nhiệm vụ cộng lại trên tất cả các nhiệm vụ .

Phân tích số liệu có thể đơn giản hoặc phức tạp tùy theo cách bạn thực hiện. Cách tiếp cận đơn giản nhất là hỏi, “Có bao nhiêu người kiểm thử cho mỗi nhà phát triển (developer) trong một dự án?” Một cách tiếp cận đáng tin cậy hơn bao gồm phân loại dự án theo quy mô (nhỏ, trung bình hoặc lớn) và độ phức tạp (đơn giản, trung bình hoặc phức tạp) và sau đó xem trung bình các dự án có quy mô cụ thể và sự kết hợp phức tạp đã mất bao lâu trong quá khứ.

Một cách tiếp cận đơn giản và đáng tin cậy khác mà là xem xét nỗ lực trung bình trên mỗi trường hợp kiểm thử trong các dự án tương tự trước đây và sử dụng số lượng trường hợp kiểm thử ước tính để ước tính tổng số nỗ lực. Các phương pháp tiếp cận tinh vi liên quan đến việc xây dựng các mô hình toán học trong một bảng tính xem xét mức trung bình trong lịch sử hoặc ngành đối với các tham số chính nhất định (số lần kiểm thử do người kiểm thử thực hiện mỗi ngày, số lượng lỗi mà người thử nghiệm tìm thấy mỗi ngày…) và sau đó đưa các tham số đó vào để dự đoán thời lượng và nỗ lực cho các nhiệm vụ hoặc hoạt động chính trong dự án của bạn. Tỷ lệ giữa người kiểm thử và nhà phát triển là một ví dụ về kỹ thuật ước tính từ trên xuống, trong đó toàn bộ ước tính được lấy ở cấp độ dự án, trong khi kỹ thuật tham số là từ dưới lên, ít nhất là khi nó được sử dụng để ước tính các nhiệm vụ riêng lẻ hoặc các hoạt động.

Bắt đầu bằng cách sử dụng trí tuệ của nhóm để tạo cấu trúc phân chia công việc và ước tính chi tiết từ dưới lên. Sau đó, áp dụng các mô hình và quy tắc ngón tay cái để kiểm thử và điều chỉnh ước tính từ dưới lên và từ trên xuống bằng cách sử dụng lịch sử trong quá khứ. Cách tiếp cận này có xu hướng tạo ra một ước tính vừa chính xác hơn vừa dễ bảo vệ hơn so với kỹ thuật của chính nó.

Ngay cả ước tính tốt nhất cũng phải được thương lượng với đội quản lý. Các phiên thương lượng thể hiện sự đa dạng đáng kinh ngạc, tùy thuộc vào những người tham gia. Tuy nhiên, có một số vị trí thương lượng kinh điển. Không có gì lạ khi trưởng nhóm kiểm thử hoặc người quản lý cố gắng đưa cho nhóm quản lý giá trị gia tăng do kiểm thử mang lại hoặc để cảnh báo đội quản lý về các vấn đề tiềm ẩn có thể xảy ra do không kiểm thử đủ.

Không có gì lạ khi đội quản lý tìm kiếm những cách thông minh để đẩy nhanh tiến độ hoặc thúc đẩy mức độ phù hợp tương đương trong thời gian ngắn hơn hoặc với ít nguồn lực hơn. Ở giữa các vị trí này, bạn và đồng nghiệp của mình có thể đạt được thỏa hiệp, nếu các bên sẵn sàng. Các cuộc thương lượng thành công về ước lượng là những cuộc thương lượng ít tập trung vào thắng thua mà tập trung nhiều hơn vào việc tìm ra cách tốt nhất để cân bằng áp lực cạnh tranh giữa chất lượng, tiến độ, ngân sách và tính năng.

Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây

Ezami

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *