"Don't crawl over bugs-per-function point or per capture; you need five or 10 basic metrics to make meaningful results, like the ability to development versus quality [output], and they should be taken over six months and balanced against industrial data," he said.

The need for software testing is determined by the context, scale and risk environment of the project, according to the Software QA and Testing Resource Center. The Web site claims testing may not be required for small projects if software programmers are experienced and skilled, and initial testing is employed.

"In some cases [where] an organization is too small or new to have a testing staff, it may be appropriate to use contractors or outsourcing, or to adjust the project management and development approach," the site states.

"Inexperienced managers sometimes gamble on the success of a project by skipping testing or getting programmers to do post-development functional testing of their work, [which is] a high-risk gamble."

Greg Sherwood, unit head of Sydney-based Squiz.net's open source content management tool MySource Matrix, said software testing should be retained in-house because business has a better understanding of its client and product requirements than outsourcing companies.

"We know our product best and we know how our clients use it and what they are most concerned about [and] we tailor our tests and testing frameworks based on that knowledge," Sherwood said, adding that testing the surface functionality of its flagship product is inadequate because it is highly complex.

"You need to measure the effectiveness of your software testing processes and constantly improve them. Each organization needs to find metrics that suit their product, like code coverage or database performance, and measure them constantly because of product changes during the development phase.

However, Sherwood said while automation tools are available for most programming languages and unit testing has grown in popularity, open source products are "notorious for being badly tested". He said automation is the best way to ensure consistent quality of testing.

Sherwood refuted figures that claim 85 percent of defects in software projects originate in the requirements phase, and said software defects creep into the product during the system architecture design, and development phases.

"It's easy to see that fixing bugs in post-implementation is significantly more expensive than bug fixes made before the product is released to users, when you consider the time it takes to upgrade and test a client's system after a bug fix," Sherwood said.

"Is it 100 times more costly? That depends on how many client systems are affected by the bug out in the wild and how those systems are patched."