When it comes time to begin software testing for your latest project, one of the most daunting tasks to many developers is creating a testing time line for how long this step will take. Recently, we posted a white paper called “Test Estimation Best Practices” on this topic, so this will be a brief summary of that piece. Estimation varies greatly depending on the project and its industry; obviously a large system that has never been tested will require far more resources than the rerelease of a smaller one. Please note also that we’re speaking specifically here about those large, unique systems, not simple websites that can be tested in only a few days.
Plan for testing to take twice the minimum amount of time in which it could realistically be completed.
To give you a starting point to determine how long your testing will take, we have devised the following formula:
The first figure will be the time needed to define the scope or your testing effort- this is when to write requirements and generate a system breakdown- for which we typically recommend a week or two, depending on the size of the system. 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. Inside the parentheses is the formula for determining the rest of the test cycles and the development time that must come in between them (which will take about a third as long as each test cycle). Then, multiplying these figures by the number of test cycles which you expect to perform will give you an estimation of your testing time.
Another tip: plan for testing to take twice the minimum amount of time that it could realistically be completed in. For example, a fairly simple system could probably be tested in only two weeks, if everything went perfectly and there were no unexpected delays. However, it’s always better to err on the side of caution, so we recommend doubling that and allotting four weeks for testing. This takes the unexpected into account, such as tests that take longer than assumed or external problems with developers or other teams who are vital to the testing process.
Of course, when estimating test time, there’s no one approach that will work for everyone. Every system in every industry has unique requirements that testing must take into account; the testing process for a hospital’s internal computer system will obviously be a bigger undertaking than the rerelease of a mobile shopping app. But despite the variance, the information above is the best way to begin estimating how long any particular testing project will take; if the proper steps are still unclear to you, try taking a look at the white paper in its entirety here, or feel free to contact us for more information.
