System design for ease of testing

Peter Zimmerer, from Siemens, says that in the system, testability must be explicitly designed. Test architects should drive ease of testing and work with architects, designers and testers to work with good design and engineering practices.

At the Qa&test 2014 conference, Peter contributed a design tutorial on the testability of embedded software systems.

Peter's definition of testability is "the degree to which a system can be tested efficiently and efficiently". Efficiency is related to the depth of the buildup and the quality of the test, which means effectively reducing costs, workload, and testing time. Testability is an easy way to confirm that the software can be tested efficiently. It plays a role in the early stages of software development and maintenance, and testability can be thought of as the ability of modified software to be recognized.

According to Peter, the main factors that affect testability are:

• Control (instability): We have a better control system (in isolation), and more, better tests can be executed, automated, and optimized.
• Visibility or observable: You can see what can be tested. You can observe the input, output, state, internal components, error conditions, resource utilization, and other aspects of the system's impact on testing.

"Testability is often a more economical investment than automation," says Peter. At the same time, automation relies on testability, and if the system is designed to be testable, it will also reduce the effort required for automated testing.

Why is it important to design for testability, and how can you persuade managers to invest in it? Its primary benefit is the ability to reduce costs, workload and commissioning, diagnostic time, and maintenance costs throughout the software development lifecycle. Peter cites Stefan Jungmayr's survey of the German test community, which was described in Testbarkeitsfaktoren und Testaufwand:auswertung Dreier Umfragen; Testbarkeitsanforderungen a die software one of the conclusions is that testability can save about 10% of the overall development budget.

Design for testability must be done jointly by architects, developers, and testers. Peter says architects are willing to accept easy-to-test designs. Testability is a design criterion, and testers must define testability requirements. In agile, testability is the responsibility of the entire team, but it can be beneficial to have a special person (such as a test architect) to drive the testability.

Peter contributed a checklist for easy-to-test design in his presentation. This checklist can be used to discuss the extent to which a team or project is dealing with testability, and what can be done to improve it:

• Proper test architecture, good design principles
• Interact with the system at test time with well-defined control points and observable points
• Additional (scriptable) interfaces, ports, hooks, simulations, interceptors for testing purposes (installation, configuration, impersonation, recovery)
• Coding guidelines, naming conventions
• Internal software quality (architecture, code)
• Built self-test, built-in test
• Conformance testing (assertions, contractual design, deviations)
• Logging and tracking (aspect-oriented program design, counters, monitors, profiling, profiling)
• Diagnostic and dump tools, black box (internal state, resource utilization, abnormal behavior during operation)
• Test-First Thinking (XTDD): How can I test it?

Through the application of good design practice can be done for easy to test the design. That's exactly what Peter says is why architects play a very important role here. Doing agile actually means doing a good job of agile engineering practice. Peter mentions the clean code developer Wikipedia, which includes principles and practices for doing better software.

Design strategies for testability need to involve requirements, testing, and architecture. Testability needs to be consistently defined and fully understood by everyone involved, who participates in or is responsible for risk-based testing strategies and maintains the stability of non-functional requirements. Easy-to-test guidelines can be used in the design to prescribe ease of testing and inline testability. Milestones and quality gates need to have easy-to-test criteria, both for static testing and for dynamic testing, which must be researched and explored for testability.

"Ignoring testability means increasing technical debt," he concludes with the phrase as his tutorial.

System design for ease of testing