Tip

Tips for estimating test step execution

Karen N. Johnson and Mike Kelly

While it isn't possible to create generic calculations for things like test execution and test script creation without knowing something about the context of the situation, there are general practices you can follow that will help you estimate test steps. Test experts Karen N. Johnson and Mike Kelly provide advice to a listener from their recent webcast,

    Requires Free Membership to View

"How to plan your software tests."


We don't currently know of any way to create generic calculations for things like test execution and test script creation without knowing something about the context of the situation. There are just too many factors that can influence calculations like those for us to be able to come up with anything reasonable.

If your project team has worked together before and you can look at your test execution velocity for past projects, you should have some idea of how fast your team can execute if the work is similar in form and scope.

More information on software test planning
How to estimate for testing on a new software project

Test plan and test strategy explained

Tips for planning, conducting load tests on Web applications

If this is your first time working together as a team, or if the work is significantly different, you may just need to set high-level execution goals for each round of testing and adjust your estimates as the project unfolds. To better make the adjustments, create a burn-down chart as your project progresses measuring how fast your team executes their tests. You may also find it helpful to track downtime (time where you're team can't test). Those two measures can be helpful in correcting any early estimates you made based on the goals you set.

You might also find that depending on how buggy the first software releases are, the speed of test execution will be impacted. The more defects being found and reported, the slower the testing will proceed – which is one reason speed of execution might not be a good measure of project progression. You might find that adding the number of defects reported is just as valuable of a measurement as the number of test cases executed.

Determining when to include automation depends on the type of automation your team will be doing. Depending on the goals of the automation, you may start writing it before your manual test phase begins. It may also depend on who the resources are and what other work they have on their plate. If the automation effort is significant, you may want to plan it out separately, noting dependencies with other test project work as you go.


This was first published in January 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.