Testimation (Test+estimation) – The daunting task of all Testers

All experienced professionals realize that one of the most daunting task is to determine exactly how long the testing process is going to take from end to end. It seems a difficult task to create a testing time line for how long a step can take. The estimation process is a complex one which contributes to the length, cost, and quality of a finished project.

Estimation depends heavily on the specifics of each individual project, obviously a large system that has never been tested will require far more resources than the re release of a smaller one.

What is Estimation?

“Estimation is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable.” [Wiki Definition]

The calculation of test estimation techniques is based on:

  • Past Data/Past experience
  • Available documents/Knowledge
  • Assumptions
  • Calculated risks

How long will software testing take?

For the most part, estimation varies greatly depending on the project itself. Obviously, larger and more complex projects, like a hospital’s computer system, will take much more planning than smaller ones like a mobile shopping app. There are many variables in a testing project, such as the size of the test team, the scope of the testing project, and the time you have to get it all done. Are you testing a large, brand new system? It’s safe to assume that this project will need considerably large areas of functional testing, requiring you to cover both functional expectations and unexpected bugs. Or are you testing a fairly stable re release with minimal code changes, considerably cutting down the areas of deep functional testing? Obviously testing these two systems will utilize very different techniques, and therefore will take very different amounts of time to test thoroughly.

Another consideration is, how much of the testing process has already occurred? While testers don’t go into a new project expecting much to be done for them already, when the requirements have already been written by the development team or a system breakdown has already been performed, less time needs to be put in by the testers themselves. Outlining the functional expectations for testers allows them to work in a much more streamlined fashion. For the most part, by the time our testers come in, companies either have already developed a good deal of expected tests, or that step is our testers’ main duty during their time there: laying the groundwork for others to test with later.

Factors Affecting Software Test Estimation

Think of Some Buffer Time – The estimation should include some buffer. But do not add a buffer, which is not realistic. Having a buffer in the estimation enables to cope for any delays that may occur. Having a buffer also helps to ensure maximum test coverage.

Keep in mind the Bug Cycle – The test estimation also includes the bug cycle.  The actual test cycle may take more days than estimated. To avoid this, we should consider the fact that test cycle depends on the stability of the build. If the build is not stable, then developers may need more time to fix and obviously the testing cycle gets extended automatically.

Availability of Resources for Estimated Period – The test estimation should consider all the leaves planned by the team members in the next few weeks or next few months. This will ensure that the estimations are realistic. The estimation should consider some fixed number of resources for test cycle. If the number of resources reduces then the estimation should be re-visited and updated accordingly.

How about Parallel Testing? – Do you have some previous versions of same product so that you can compare the output? If yes, then this can make your testing task bit easier. You should think the estimation based on your product version.

Estimations cannot always be accurate – Re-visit the estimations frequently in initial stages before you commit it. In early stages, we should frequently re-visit the test estimations and make modification if needed. We should not extend the estimation once we freeze it, unless there are major changes in requirement.

Consider your past experience before making judgments – Experiences from past projects play a vital role while preparing the time estimates. We can try to avoid all the difficulties or issues that were faced in past projects. We can analyze how the previous estimates were and how much they helped to deliver product on time.

Consider the Scope of Project – Know what is the end objective of the project and list all the final deliverables. Factors to be considered for small and large projects differ a lot. Large project, typically include setting up test bed, generating test data, test scripts etc. Hence the estimations should be based on all these factors. Whereas in small projects, typically the test cycle include test cases writing, execution and regression.

Want to go for Load Testing?  – If you need to put considerable time on performance testing then estimate accordingly. Estimations for projects, which involve load testing, should be considered differently.

Team plays an important role – Know them all – If you know the strengths and weaknesses of individuals working in your team then you can estimate testing tasks more precisely. While estimating one should consider the fact that all resources may not yield same productivity level. Some people can execute faster compared to others. Though this is not a major factor but it adds up to the total delay in deliverable s.

Testers should always note when estimating test time, there’s no one universal approach that will work best for everyone. Every system for every industry will be inherently different in its clientele, system requirements, and software testing best practices. However, despite this variance, businesses and developers must still estimate how long their testing will take when determining their costs and release dates, and they need a framework to build off of for that. Test estimation should be realistic and accurate.