Testability matters

Oct 1, 2014

Capgemini

Testers are detectives. Often I spend a lot of time investigating how a certain software program that needs adaptation can be tested. Some issues are:

• The system is not documented well and people don’t seem to be sure how the system is built-up and where the changes are needed exactly.
• The system is a giant black box of which the output does not always tell us much about whether the internal behavior is as required.
• The software interacts with other systems, but it is a mystery whether that interaction can happen in the same way in the test environment or what is needed for it to work, theoretically.

In those cases, test execution often turns out to be hard, error-prone, and slow – even for small program changes.

In any project approach you take, testability of the software that is being created or amended is a decisive factor in the time and cost of testing. When the required effort is deemed too much and management decides to drop (part of) testing, it brings risk, a potential loss of quality, and a lack of confidence in the product.

Testing is not a one-time activity, however. Software is a living thing that constantly needs to catch up with its users’ demands, so testing is something that needs to be done throughout the life span of the software whenever changes are made to it – and I promise you there will be changes.

In that perspective, investing in the testability of a system gives return over its entire life span. TMap® recognizes this value and lists testability itself as a quality characteristic of a software system, alongside all-time classics like functionality, security, and performance.

There are a number of measures that can be taken to improve the testability of a system:

Improve transparency about what the system does and what it is supposed to do:

• Keep updated system documentation
• Write readable, well-structured code
• Have a solid test basis (clear software requirements)

Use technologies and write code by which parts of the system can be tested in isolation:

• Maintain a proper separation of concerns
• Allow interim results of the system to be made visible, assessed, and even manipulated

Set up a full-fledged test environment:

• Find the right balance between representativeness and flexibility (e.g. adjustable system date for purposes of time travel)
• Opt for technologies for which, or in which, tests can easily be automated

These measures may not be the first thing on the mind of any project manager, but they sure make the work of both developers and testers a lot easier and more effective, especially in the longer term, enabling to build in better quality while generally reducing the software’s total cost of ownership at the same time.

About the author

Wannes Lauwers

Software Testing Professional | Belgium

Wannes Lauwers has been working with Sogeti since 2012 as a versatile software testing professional who manages to bridge the gap between business and IT in a variety of industries thanks to his broad interests and educational background in business administration. With his process mindset, Wannes is committed to deliver long term solutions well aligned with business needs, thus guiding companies’ convergence of business and IT into true business technology. Wannes has a special affinity for web applications and language technology.

Comments