Capitalizing Testware as an Asset

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, and 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 its 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 effort (and the entire product development).
  • 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 (AUT), 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.

Hans Buwalda

Hans leads LogiGear’s research and development of test automation solutions, and the delivery of advanced test automation consulting and engineering services. He is a pioneer of the keyword approach for software testing organizations, and he assists clients in strategic implementation of the Action Based Testing™ method throughout their testing organizations.

Hans is also the original architect of LogiGear’s TestArchitect™, the modular keyword-driven toolset for software test design, automation and management. Hans is an internationally recognized expert on test automation, test development and testing technology management. He is coauthor of Integrated Test Design and Automation (Addison Wesley, 2001), and speaks frequently at international testing conferences.

Hans holds a Master of Science in Computer Science from Free University, Amsterdam.

Hans Buwalda
Hans Buwalda, CTO of LogiGear, is a pioneer of the Action Based and Soap Opera methodologies of testing and automation, and lead developer of TestArchitect, LogiGear’s keyword-based toolset for software test design, automation and management. He is co-author of Integrated Test Design and Automation, and a frequent speaker at test conferences.

The Related Post

People who follow me on twitter or via my blog might be aware that I have a wide range of interests in areas outside my normal testing job. I like to research and learn different things, especially psychology and see if it may benefit and improve my skills and approaches during my normal testing job. ...
Karen N. Johnson began as a technical writer in 1985 and later switched to software testing in 1992. She maintains a blog at TestingReflections, a collaborative site where she is featured as a main contributor. In her latest entry, she discusses search testing with different languages. Here is an excerpt from her blog: “I started ...
Test organizations continue to undergo rapid transformation as demands grow for testing efficiencies. Functional test automation is often seen as a way to increase the overall efficiency of functional and system tests. How can a test organization stage itself for functional test automation before an investment in test automation has even been made? Further, how ...
Introduction All too often, senior management judges Software Testing success through the lens of potential cost savings. Test Automation and outsourcing are looked at as simple methods to reduce the costs of Software Testing; but, the sad truth is that simply automating or offshoring for the sake of automating or offshoring will only yield poor ...
Introduction This 2 article series describes activities that are central to successfully integrating application performance testing into an Agile process. The activities described here specifically target performance specialists who are new to the practice of fully integrating performance testing into an Agile or other iteratively-based process, though many of the concepts and considerations can be ...
Please note: This article was adapted from a blog posting in Karen N. Johnson’s blog on July 24, 2007. Introduction The password field is one data entry field that needs special attention when testing an application. The password field can be important (since accessing someone’s account can start a security leak), testers should spend more ...
D. Richard Kuhn – Computer Scientist, National Institute of Standards & Technology LogiGear: How did you get into software testing? What did you find interesting about it? Mr. Kuhn: About 10 years ago Dolores Wallace and I were investigating the causes of software failures in medical devices, using 15 years of data from the FDA. ...
At VISTACON 2011, Jane sat down with LogiGear Sr. VP, Michael Hackett, to discuss complex systems.
Do testers have to write code? For years, whenever someone asked me if I thought testers had to know how to write code, I’ve responded: “Of course not.” The way I see it, test automation is inherently a programming activity. Anyone tasked with automating tests should know how to program. But not all testers are ...
Training has to be fun. Simple as that. To inspire changed behaviors and adoption of new practices, training has to be interesting, motivating, stimulating and challenging. Training also has to be engaging enough to maintain interest, as trainers today are forced to compete with handheld mobile devices, interruptions from texting, email distractions, and people who think they ...
LogiGear Magazine – July 2011 – The Test Methods & Strategies Issue
When You’re Out to Fix Bottlenecks, Be Sure You’re Able to Distinguish Them From System Failures and Slow Spots Bottlenecks are likely to be lurking in your application. Here’s how you as a performance tester can find them. This article first appeared in Software Test & Performance, May 2005. So you found an odd pattern ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe