You are a test automation engineer and one of your jobs depending on the seniority of course, is to try to consider all the System-Under-Test(SUT) factors that will allow you to better prepare for a successful test automation. You maybe wondering where do you start, what kind of thinking or approach you need to follow, what kind of tools to utilize depending on the business context and the SUT. Assuming that a formal test automation strategy is already created and applied troughout the organization, the next action is obviously, taking into acount al the factors influencing the test automation.
SUT factors that influence test automation
When considering the context of the SUT, there can be alot of factors that can influence the test automation preparation. These must be identified as early as possible but in general, they can fall into several categories.
Available SUT interfaces
The automated test scripts are performing some actions on the SUT and to do that there must be some kind of an interface to allow these actions and communication between the tests and the SUT. This can be achieved using the SUT UI or some lower level interfces available for unit or system tests.
From my personal experience, automated testing on the lower levels require an exposed API to test the core unctionalities or some kind of a customized interface that will allow you to perform various type of actions on the SUT.
Third-party software
Also one of the important SUT factors, the third-party software can be part of the SUT since in many organizations, the applications are not developed only in-house and therefore require the help of an external software to properly function.
If that’s the case then you need to also consider including this software as part of your test automation preparation and be sure to cover the communication between that software and the main SUT.
Level of intrusion
Usually different test automation approach comes with different level of intrusion. When you automate UI elements(and those are the same the end user would use) that’s an example of low level of intrusion. But for example, if some of the UI elements are not accessible or you have a problem performing actions on them and you need to rely on the SUT’s private API, that can be an example of high level of intrusion hwere you can find many other issues that the end-sure would not.
Testing with high level of intrusion is simplier but it can result with false positives.
SUT architecture
Another important part of the SUT factors is the SUT architecture itself. You cannot perform test automation using the same framework on different SUTs with different architecture. For example SUT written in Python is different with the one wrtten in Java following some design patterns in development.
But in that case what you can do is having some kind of a hybrid framework where it can support multiple differet SUTs even though the effort required to do this is signifcanlty bigger and more complex.
Complexity
The last of the SUT factors list is the SUT complexity. If the SUT size and complexity is higher than usual, then you need to consider starting with a simplier test automation preparation approach. Even though if the SUT complexity is high, you still need to start with the simpliest approach and then go further with your test automation implementation to satisfy the SUT automation coverage.
You can even have a test automation planning structure completed before the developemnt of the SUT. If the requirements are there, then those can be selected as candidates for automation and plan for them. Also when the architecture and design is being develope the design of the interfaces that suport testing can be taken into consideration.
