Interface to the System Under Test

Different systems under test will have varying levels of accessibility and will require different approaches for interfacing with them. Here are some general guidelines for interfacing with SUTs and infrastructure components, keeping in mind that in some cases, developers may need to be involved in the design and creation of interface code

Leverage existing APIs: Many systems and components will already have APIs (Application Programming Interfaces) that can be used for monitoring, control, and failure injection. Utilize these APIs whenever possible to minimize the need for custom interfaces or shims.

Implement shims when necessary: If a system or component does not have an existing API or interface suitable for testing purposes, you may need to develop a "shim" to provide the required functionality. A shim can be a software component that sits between the test platform and the system under test, converting dat andcommands between the two.

Collaborate with developers: In situations where a shim is required or the existing interface is not suitable, involve the system's developers in the design and implementation process. Their knowledge of the system's internals can be invaluable in creating an effective interface and ensuring it meets the needs of the test team.

Monitor and control: Ensure that the interfaces and shims you develop or utilize provide the necessary functionality to monitor the status of the system or component, as well as to inject failures and control their behavior. This is essential for comprehensive testing and validation of the system's resilience and robustness.

Documentation and support: It's nice to say everything should be well documented but often that reality gets left on the table. If you can get access to a tech writer get one! If not, make use of in-line documentation.