Capitalizing Testware as an Asset

By Hans Buwalda, Chief Architect, LogiGear Corporation

Companies generally consider the software they own, whether it is created in-house or acquired, as an asset (something that could appear on the balance sheet). The production of software impacts the profit and loss accounts for the year it is produced: The resources used to produce the software result in costs; methods, tools or practices that reduce those costs are considered profitable.

Software testing is generally regarded as an activity, not a product: the test team tests the products of the development team. In that sense testing is seen in terms of costs and savings: The activity costs money; finding bugs early saves money. Test automation can reduce the cost of the testing itself.

Managing the testing effort in financial terms of profit and loss (costs and savings) is a good thing, particularly if it leads managers to make conscious decisions about the amount of testing that should be performed: More testing costs more, and less testing increases risks, which are potential (often much higher) costs down the line.

Very few companies think of software tests as products, or in financial terms, company assets. Test teams are not seen as "producing" anything. This is unfortunate, since it underestimates, particularly in financial terms, the value of good "testware".

The underlying reasons for not treating testware as a long term assets are hardly surprising:

• In manual testing, the bulk of the hours are spent executing tests against the system, even if test cases are documented in a test plan.
• In most test automation projects, the test scripts are not well architected and too sensitive to system changes.

If an organization begins to consider it's tests as assets, then it can significantly enhance the way that it approaches testing. Consider the following:

• Test cases for your application have a definite value, and just like any other capital asset, can depreciate over time as the underlying application changes.
• Well-written test cases, along with thoroughly documented requirements and specifications, are one of the few ways to consolidate the 'intellectual capital' of your team members. With today's global teams, and the increasing challenge of retaining engineers, especially overseas, being able to retain knowledge as people come and go is critical to the success of your testing (and the entire product development) effort.
• Well-automated tests can be re-used over and over again, thus forming assets which produce profits for the company.

So how can you apply this idea at your company?

Creating automated tests is the best way I've found to maximize the output of your investment in software testing. Not only does test automation reduce your costs (a positive impact to your P&L), but well-designed test automation is also a valuable asset (a positive impact on the balance sheet of the company) that can be used across many different versions of your product, even as you switch between platforms!

• As much as possible, define your tests at the 'business process' level, leaving out unneeded details of the application under test, like its UI build-up or screen flow. Business processes change less frequently than the systems that are supporting them, so your test will require less maintenance (i.e. depreciate less quickly.)
• The tests should be executable either automatically or manually, so that they still provide value even when the system has changed and some updates to the automation are required. Keyword-driven testing is a great example of how tests can be defined in a format that can be executed either way.
• Remember that test automation tools are not silver bullets. To maximize the output of your investment in test automation, you must combine good methodology and technology. A poorly planned test automation effort can quickly become a burden on your organization that provides little value.