Automation is no magic. Like any other coding activity, it needs careful planning. Physical code has to be written, tested, and deployed. It needs continuous updating when the application grows and test cases are added or modified. Teams often complain that while writing test cases is a tedious task, maintaining tests is more difficult. The business logic changes continuously and this makes the task of updating test cases very difficult. As the number of test cases increases, the regression suite also grows in size, and executing all of them continuously is too time consuming and boring. Test automation is an answer to these issues, where tests are executed daily with minimum monitoring required 💪
The Three Layer Framework
If we are automating our test cases, we need to make sure it is packaged inside a framework. The framework itself should be robust and scalable, keeping in mind that more test cases may be added to the automation suite and the framework should support them. Therefore the framework needs to be well thought of and planned in such a way that it can support script expansions. There are various frameworks available off the shelf that can be customized as per your needs. However, many organizations prefer to write their own frameworks that suit all their automation needs.
Test automation has code written to test logic and involves testing some supporting code like parsing, UI accessibility, etc.. Since test logic is hidden inside this code, it becomes difficult to read and maintain it. As a solution, test teams rely on a layered architecture, which consists of three layers:
1️⃣ Test Logic Layer – which involves the test cases covering the application under test. All the test logic is present here.
2️⃣ Domain Interface Layer – which covers domain to be tested, various browsers, and parsing logic. It also provides an interface for the test logic layer.
3️⃣ System Layer – which is the actual system under test. The domain interface layer interacts with this layer.
The test logic layer consists of test cases that are automated. These test cases are based on the domain interface layer which encapsulates the system under test in its modular form. The Domain interface layer accesses the system under test directly.
Examples:
The Test Logic Layer looks like the following:
[Jira Story 1]
[Test Scenario 1]
public void IsLoginWithCorrectCredentials()
{
}
[Test Scenario 2]
public void IsLoginWithBlankCredentials()
{
}
[Test Scenario 3]
[Test Scenario 4]
{Test Scenario 5}
{Test Scenario n}
The Domain Interface Layer Includes the domain in a modular form. Each module is represented by a public class. Looking at this complete representation, the business can check whether any module is left from being automated. The best way to go about doing this is to first draw block diagrams of the modules. Each box represents one module. Within a module, you can write the functional tasks. The numbering decides the inter-modular flow.
Now each box represents one class in the automation code:
public class OrderSearch
{
public Subscriber CustomerOpensSite(string SiteName)
{
// do the tasks
}
…
}
The System Layer is the actual system under test.
Benefits of The Three Layered Automation Framework
The following benefits were experienced by various automation teams:
- The test case maintenance becomes simpler, as the separate test case layer helps understand the test logic of the main and the supporting code. If any change is made it is directly influenced by a change in the domain layer. Hence it is almost guaranteed that any changes that are made will execute fine.
- The updates of tests which are often fragile, may not impact the system under test directly, as this system layer is separated from the test case layer by the presence of the domain layer in between.
- Maintenance cost is reduced as tests need to be changed in only one layer- no duplication of effort. Since the services and domain models are encapsulating the system under test, the code is easier to understand and modify.
- It also ensures that developers and QAs work on different layers. While developers focus on the domain layer and write code, QAs ensure the test layer is up to date and modify test cases when deemed.
Conclusion
The success of automation lies in the architecture of its framework. The three layered architecture suits most applications that are being developed. It helps both developers and QAs to focus on their tasks in hand. Design the framework for your requirements and use the benefits of automation 💫