New projects or new stories often require testing time estimates for planning purposes. Most software test planning...
is one part fiction, two parts reality, one part wishful thinking and three parts pure fantasy. In general, I'm not convinced testing estimates are useful, especially for Agile development teams, but they are usually required, and it's best to attempt to give the most accurate estimate you can.
Accuracy in software test planning is important for project managers and/or teams to judge how long a project will take to complete. The problem, as a QA tester, is that a testing estimate depends on how things go. How hard is setup and data creation? Is the developer a careful creator or more of a wing and a prayer developer? Are there other applications involved, especially external ones? These questions are important because they tell me how much testing I have to cover and how thoroughly it must be covered.
There are many variable factors for the QA tester to consider when calculating an accurate testing estimate. At a minimum, the following factors must be considered:
- Developer history
- Test's impact on your environment
- Integrated objects -- internal and external
- QA workload
- Priority of existing, in-progress testing work
For the developer, think about the code quality that your developer typically produces. Does the developer tend to test his/her code superficially or are they more thorough? Does he/she have a history of not understanding the application workflow or the details in the application itself? Finally, can you track him or her down for questions or if problems are found?
Next, consider the complexity of the workflow. How much of the application needs to be tested and how far through the testing must you go? In other words, how involved is it to test the workflow completely? Then, there's the test's impact on your environment. Is the change simple to deploy or does it involve special set-up or deployment considerations?
Consider what integration impacts should be considered both in the internal application and, especially, with external third-party vendors.
The impact of testing with third-party vendors can be extensive. Third-party vendors aren't part of the team's schedule and likely have their own schedules and deadlines.
Finally, make sure to include your QA workload in the plan. In other words, does the software testing plan fit into the existing schedule, is it already planned or is it additional work? Also, what priority is testing? If priorities need to change, then it takes time to re-shuffle and re-organize work plans.
Testing time estimation is an important part of team planning. Be sure to take estimation into careful consideration and provide the most accurate estimate you can. Although it's tempting and feasible to pad estimates, keeping it realistic assists both the team and the QA tester in managing workload expectations and succeeding in getting quality work done on schedule.
Why third-party app add-ons are never your friend
Why hands-on testing is never going away
How the role of the software tester is changing
Dig Deeper on Software Test Design and Planning
Related Q&A from Amy Reichert
QA needs to keep reminding business of its value. Expert Amy Reichert offers tried-and-true advice on how to leverage documentation and automation to...continue reading
Contract QA jobs can pay more than staff positions, but only if you're a good negotiator. Expert Amy Reichert helps explain the differences between ...continue reading
Quality assurance professionals need to start thinking about bringing business along for the ride. Expert Amy Reichert offers tried-and-true advice ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.