Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Friday, 17 October 2008

Test Estimation - Research and Thoughts

Test Estimation, what is it and how to do it.

I think this easily joins the list of "Top 10 Most Asked Questions" that would be put together by trawling any popular forum or testing community website. There's an idea...

Someone being able to estimate, a) How long it will take to write Test Cases and b) How long it will take to execute them; is a fundamental for any test team. This assumes the person doing the estimation is reasonable at the test analysis activities or has someone in the team who is, a Test Analyst maybe?

Estimation has a number of factors of course; complexity and scope of the testing needed and of the item under test, number and competency of testing staff, the impact of development on the testing effort or more accurately the impact on the quality of the test item, the list goes on.

In Q1 2008 I had a sit down with myself and drew together a collection of thinking I'd done around this topic. I'd hoped to formulate a model that was sophisticated enough to be of use but not so convoluted that it was unusable. I've seen a lot of vague discussion about estimation and a lot of nice but complex theory that would never be usable in the heat of a project.

One usable approach can be seen in Tony's Video and there's even a worksheet on his website.

From my side I did write a paper on Test Estimation though it contains several approaches and not one - I just knew it would the moment I started writing. That I believe reflects the main issue of why we keep talking about this topic, there's no one-size-fits-all and I suspect that the 'answer' is more likely a set of guidelines and approaches, not axioms or rules.

Apply these in context of your environment to make them relevant and augment them with additional guidelines that make your approach work for you, in a way that you understand.

My paper and a JavaScript/HTML paper is posted
on the site here. It contains an image of how to complete the HTML page too as it may not be overly clear.

One other approach is to do a decomposition of the work to be done. During test analysis we'll usually try and identify all of the individual peices of functionality to be tested. Creating a collection of scenarios or test objectives for each of these and then defning a set of Test Cases. From here we can work out the individual timings for writing the Test Cases and then Executing them. In total we'll have our estimate for test prep and running.

Here's a copy of a Test Estimation Workbook that could be used for this approach. Perhaps using this after the 'main' estimate is done might be interesting. I wonder if we'd have the time!

This approach means we can also track planned against actual effort to provide some clever Measures & Metrics reporting and use the data to feedback into our future estimates.

Mark 'roughly this big' Crowther