Estimating Test Effort – From Billiard Balls to Electron Clouds

Each of us has very likely had to do an estimate in the past, whether it was for a set of assigned tasks, for a project, or for the budget of an entire organization. As a tester, the question is commonly presented as, “How long will it take to test this product – and what resources will you need?” and then the person asking stands there, likely somewhat impatiently, waiting for your answer.

Warning – What you say will be used against you at a later time! Estimation is a black box (magic?) process for many organizations and all the more so for their testing activities. The inputs used, the process and end results are therefore open to debate or worse – to un-discussed misinterpretation.

In Steve McConnell’s “Software Development’s Classic Mistakes 2008” software estimation is mentioned more than once as an area of significant impact. Of the “Top Ten Almost Always”, confusing estimates with targets was ranked #5 and shortchanging quality assurance was ranked #3. Overly optimistic schedules was ranked #1 of that list.

“…some organizations actually refer to the target as the ‘estimate,’ which lends it an unwarranted and misleading authenticity as a foundation for creating plans, schedules, and commitments.” – Steve McConnell, “Software Development’s Classic Mistakes 2008”

Capers Jones noted in Assessment and Control of Software Risks that most projects overshoot their estimated schedules anywhere from 25% to 100%, but some few organizations have achieved consistent schedule-prediction accuracies within 10% and 5%.

What are these organizations doing different? Are they the quantum physicists of software? Perhaps, but maybe they have simply taken the time to put in place a formal and repeatable estimation process tailored to the types of projects they undertake – something we all can do. Of course, we will not blindly copy these organizations’ approach. We simply need to employ similar practices in a framework of continuous improvement while recognizing that a single approach will not fit all of our needs all of the time.

Read the full article…

About Trevor Atkins

Trevor Atkins (@thinktesting) has been involved in 100’s of software projects over the last 20+ years and has a demonstrated track record of achieving rapid ROI for his customers and their business. Experienced in all project roles, Trevor’s primary focus has been on planning and execution of projects and improvement of the same, so as to optimize quality versus constraints for the business. LinkedIn Profile
This entry was posted in  All, Business of Testing, Estimation for Testing, Planning for Quality, Test Planning & Strategy and tagged , , , , . Bookmark the permalink.