Even many experienced professionals can have trouble determining exactly how long the testing process is going to take from end to end. Because it can depend so heavily on the specifics of each individual project, test estimation must be performed for every system independently of others before testing can commence. The estimation process is a complex one which contributes to the length, cost, and quality of a finished project – so how is it determined?
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 rerelease 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.
We’ve determined that the best way to test is by breaking the process down into multiple cycles. For example, let’s look at the testing process for a stereotypical large system, like a CRM or ERP system. The first step in test estimation is defining the testing scope (what exactly your tests must cover) and designing the tests themselves. This is the period during which requirements are written and system breakdowns are generated. For large systems like the one we will use in this example, this process will typically take a week or two, though for smaller systems or single web pages the process can be much shorter – a few days, or even a few hours. From there we will begin with the first test cycle, in which the majority of test cases (both manual and automated, if the system requires automation); this part usually runs 6-8 weeks, depending on the number of people and systems available.
The results of this initial cycle are sent to the development team, who typically have around 2 weeks to fix what bugs they can, particularly those which are considered blockers for testing in cycle two. This second cycle lasts about 6 weeks and focuses on running all automated tests, all manual test cases which failed in the first cycle, and any major functionality changes which have occurred between the two cycles (of which there really shouldn’t be any, unless they are fixes to bugs from the first cycle). From there, the system is again returned to the developers to give them an opportunity to fix any release blockers – best-case scenario is that this is an unnecessary precaution, as all the bugs should hopefully be fixed by now. Finally, the last cycle is run simply to see how the system works now, instead of prior cycles which attempted to “break” the system to expose its bugs. This ensures that the system runs without any interference under normal circumstances. From here, testing should be complete and the system should be ready for release.
However, every project is different, and therefore so is every testing process. It’s better to speak in hard numbers instead of generalities, so we have determined a formula for test estimation to give you a starting point for calculating your testing time.
2 weeks of scope definition + 1.5 x + (.3*x + x) * c = total testing time
When calculating this formula, the first figure should represent the time in which the initial scope definition period occurs. From there, let x represent the net testing time per cycle, and make c the number of cycles which must be completed in total. The first cycle should have some extra leeway for unexpected hold-ups, and so we multiply x times 1.5 to give it a little extra wiggle room. From there, the time the developers have to fix bugs between cycles should be about a third of x. This is represented in the parentheses in addition to the test cycle which follows the break to check that the bugs have been properly addressed. From there, we multiply by as many test cycles as we expect will be necessary to come to our total testing time. Therefore, say that we want to complete 3 cycles of 6 weeks each; according to this formula, we should expect the testing effort to take about 34.4 weeks, or around 8 months.
If you don’t want to do the math, our recommendation is to plan for testing to take much longer than the minimum time you could reasonably have it tested in. Our testers recommend determining the shortest possible amount of time it could take, and then doubling that amount – so for a system which theoretically COULD be completed in two months, plan for it to take around four instead. This accounts for bug fixes, unexpected delays in testing, blockers that were overlooked, tests that consume more time than expected, and any other roadblock that could crop up. Typically this also gives a good amount of time for delays in other areas that aren’t necessarily related to the testers themselves, but which can still affect the testing effort.
The important thing to remember when estimating test time is, 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. The information above, while general, is the most common way to start planning how long the test estimation process will take. For a more specific estimate, it is best to see a professional software testing company who can work with you to create a tailored test plan that will be as inclusive as necessary for your product, customers’ needs, and industry.
