How to Set a Software Testing Budget that Fits your Business Goals
Call it the Annual Operating Process, Mid Range, the Software Testing Budget, or even Strategic Planning. At some point, companies need to determine how much to invest in testing for the next year, and, ideally, develop a strategy for the years to come.
The list of upcoming projects is likely a set of bullet points that may or may not have a definition. Priorities for those projects, and staffing needs, could be vaguely defined, if defined at all.
Despite these challenges, leaders still need to set a software testing budget, and live with the consequences. Most leaders use some method, although they may do it unconsciously.
[ Looking to calculate your software testing ROI online? Use our free ROI calculator. It’s easy, just plug in your data to see how effective your software testing is. CALCULATE YOUR SAVINGS ]
Today we’ll look at making the method explicit, with five ways to prepare a software testing budget, the advantages and disadvantages of each, and when to use them.
1) Hold Budget To Last Years Numbers
Easy to calculate and appreciated by senior management, holding to last years software testing budget requires either no raises, or the company to pay for raises through turnover that is not replaced. Most appealing to organizations in belt tightening mode, or shifting from active development to maintenance. Most departments will want to at least add a cost of living adjustment for stepwise increases.
2) Last Year Plus Trend Demand
Take four or five years of data for annual budgets and determine the average increase, using this to project next year’s budget. Best for large organizations that have long-term demand that grows at a stable rate. Once the large budget is in place, consider the size of the pie to commit to employees, raises, contractors, vendors and other forms of technical support.
3) As a Percentage of Programming Resources
Like trend, this method requires a few years of data; not just test data but also programming staff. Using this method, you calculate the project test needs by determining the historical ratio of test-to-development cost, then multiplying that number by next year’s development budget.
4) Percentage of Development Resources Adjusted For Needs
According to CIOInsight, testing can consume as much as 25% of all IT expenses. That isn’t a percentage of programming — it is a percentage of all IT. That number is significantly higher that it was even a few years ago. If the test effort is growing as a percentage, than historical averages will fail. That means adjusting the rate based on the tempo, or demand, on the test group.
5) Zero Base Budgeting
If the projects for the next year, the staff needs, and the software and support needs are all clear, it may be possible to build a staffing plan for the needs, then project the costs. Zero based budgeting has potential to create significant cost savings — but it can also cause disruption to the organization, involve staff reductions, and worse, leave the organization unable to adapt for emergent needs. For a zero-based budgeting approach, consider keeping an extra percentage of budget in reserve.
Putting It All Together
The large number, the overall software testing budget number, is the easy part. Once the department has that, it’s time to break that number down into staff, contractors, and tools. Contractors are more expensive by the hour, but allow the department to flex staff up and down based on emergent demand. If demand is consistently growing, the percentage of contract work will be lower. Likewise, break down the tools budget, which should include licensing, support, and training.
When looking at contractor cost, consider total cost, not hourly cost. The best way to do this is to look at historical costs of contracting, both on-site and remote, compared to the overall cost of the project. In many cases a low hourly rate can involve hidden costs, like billable delays, waiting, and rework.
Because these methods are quick and easy, consider calculating the budget in a variety of ways, getting multiple answers, and considering why the numbers are different and by how much.
Finally, large test organizations will have a multi-level budget. In some cases, the budget can be determined by composition — adding up all the amounts for the lower organizations plus any headquarters staff. Often the projects are simply too large, and a series of conversations results to find a compromise. When that happens, these five methods can provide an alternative point of reference to lead to better conversations and compromises.
There are tons of agile software tools out there, but do you ever wonder how will this tool save us money? What is the return on investment of a new tool? How does this maximize our investment in testing? We have tried to answer these questions and more for modern software testing tools in a new, free ebook: The Executive Value Guide.
