AEM Test Automation

Testing as a way to ensure the highest quality is one of the key factors to deliver the best possible products. This is why ever since we founded Netcentric we focused on ways to improve our testing.

We started approaching automation as a way to enhance our products’ quality by both extending our test coverage and allowing us to have more in-depth testing rounds.

Improving quality assurance

“Exceed the highest standards and achieve results you are proud of.” This is one of the core values that Netcentric strives to achieve. Our main goal is to meet the best quality in everything we commit to. That’s why we always aim to improve the products we deliver to our clients in the most efficient way.

Adapting to customers' needs

Each of our clients has different requirements and preferences. Hence, we have to adapt to different functionalities and components in every project to tailor to their needs. This leads to a fine line between assembling a QA team that understands the expected behaviours to properly test them and automating the testing of each page, component and functionality from scratch.

Being a small team, automating each project from scratch would have been too costly and time-consuming. We had to find a more efficient way to get the desired results.

Netcentric's approach to automation

The solution to this dilemma was to follow the same approach Adobe uses with AEM: To create an API which contains all the common behaviours of an application and then extending and adapting it to the needs of each project.

Adapting to customer's needs by extending the framework's capabilities and implementing specific functionalities for the project.

The inner layer of the figure above corresponds to all the functionalities that correspond to an out-of-the-box AEM instance. Some of the most important features include everything related to checking a structure, creating a new page, adding certain components, publishing pages, checking pages in publish, and checking different component functionalities on publish.

The mid layer will extend the inner layer and adapt the existing components needed from the inner layer to the needs of each individual project. It also contains any additional component that is particularly implemented for a specific project. This way every project will be a natural extension of the AEM core project, the same way as AEM is implemented.

The third and outer layer corresponds to the actual test cases implementation. This layer will be implemented directly in the project’s repository and contains the test cases that have been automated. These tests will run against the desired environment in the project, and will report any failures or defects.

Sensible test automation

Automating test cases can be immensely useful for certain features, but it also requires time and resources to implement it in the first place. It needs time and resources to code, maintain and deliver test cases that are useful and that provide meaningful quality to the project.

That’s why creating cases for test automation involves a great deal of careful consideration. If used the right way it will save unnecessary costs and resources in the long run, but it shouldn't be used in every case.

We need to carefully select which test cases fulfil the necessary requirements: the stability of the environment and the repetition of tasks are key factors to determine if a task can be automated or not. If a page is in development stage and constantly changes or a test case will only be executed once during testing round it's not advisable to automate it.

Complementing quality assurance

At the end of the day, automation will not substitute manual QA. Instead, it can be used to skyrocket the quality of delivered products: It allows the QA Engineers to do in-depth test rounds and spend time on testing more specific and complex issues while the automation takes care of more repetitive tasks.

On the developer side, it can also improve their code before it is even forwarded to a QA engineer. Test automation can check that the code committed doesn't break any functional aspect of a page.

In the long term automation can be used to support quality assurance engineers and give them time and resources to test complex functionality of an application. This in return improves the quality of products in general as it allows a more in-depth and thorough testing of an application.