The testability of the SUT (availability of software interfaces that support testing, e.g., to control and observe the SUT) should be designed and implemented in parallel with the design and implementation of the other implementation of the other features of the SUT. This can be done by the software architect (since testability is testability only one of the non-functional requirements of the system), but often this is done by or with the involvement of a TAE.

Design for testability consists of several parts:

• Observability: The SUT must provide interfaces that allow insight into the system. Test cases Test cases can use these interfaces to check, for example, whether the expected behavior matches the actual behavior.
• Control(s) Capability: The SUT shall provide interfaces through which actions can be performed on the SUT. SUT. These can be UI elements, function calls, communication elements (e.g. TCP/IP or USB protocol), electronic signals (for physical switches), etc.
• Clearly defined architecture: The third important part of designing for testability is an architecture that provides clear and understandable interfaces that enable control and visibility at all levels of testing.

The TAE considers ways to test the SUT in an effective (test the right areas and find critical bugs) and efficient (without too much effort) manner, including automated testing. Whenever specific software interfaces are needed, they must be specified by the TAE and implemented by the developer. It is important to define testability and, if needed, additional software interfaces early in the project so that development work can be planned and budgeted.

Some examples of software interfaces that support testing are:

• The powerful scripting capabilities of modern spreadsheets.
• The use of stubs or mocks to simulate software and/or hardware (e.g., electronic financial transactions financial transactions, software services, dedicated servers, electronic circuit boards, mechanical parts) that is not yet available or too expensive to purchase allows testing of the software in the absence of that specific interface.
• Software interfaces (or stubs and drivers) can be used to test fault conditions. Consider a device with an internal hard disk drive (HDD). The software that controls this HDD (called a driver) should be tested for HDD failures or wear. Doing this by waiting until a hard drive fails is not very efficient (or reliable). By implementing software interfaces that simulate failing or slow hard disks, it is possible to verify that the driver software is working correctly (e.g., gives an error message, retries).
• Alternative software interfaces can be used to test a SUT when no user interface is yet available (and this is often considered the better approach anyway). Embedded software in engineering systems often needs to monitor the temperature in the device and trigger a cooling function if the temperature rises above a certain value. This could be tested without the hardware by using a software interface to specify the temperature.
• State transition tests are used to evaluate the state behavior of the SUT. One way to verify that the SUT is in the correct state is to query it using a software interface designed specifically for this purpose.

The design for automation should take this into account:

• Compatibility with existing test tools should be determined early on.
• The issue of test tool compatibility is critical in that it can affect the ability to automate tests for important functions. important functions (e.g., incompatibility with a grid control prevents all tests using that control).
• Solutions may require development of program code and calls to APIs.

Designing for testability is essential to a good test automation approach and can also benefit manual test execution.

Source: ISTQB®: CTAL Test Automation Engineer Syllabus Version 1.0