Automation of SIT Tests in the Development and Deployment of a Consent Manager on Web Platforms of a Multinational Company

Introduction

With the arrival of GDPR, the client (a multinational corporation in automotive industry, which is directly or indirectly responsible for dozens of web portals in a number of countries around the world) faced the need to deploy an appropriate solution for managing visitors' consents according to individual types of cookies.

Launch of web analytics, or its limited version, etc. is then linked to the consents granted to the individual types of cookies.

If this so-called "Consent Manager" had not been deployed, or if it had not worked properly, the client would have faced significant financial sanctions.

How it Started

For this project, we were tasked with creating automated SIT tests in a range of scenarios that were discussed with the product owner and business analyst. However, during the development and subsequent deployment process, the tests themselves and together with their architecture underwent a relatively dynamic and fundamental development. Before starting the project, the client decided on the following solution:

• The Consent Manager itself, its technical support and development were supplied by an external company as a ready-made product meeting all client requirements
• However, the Consent Manager had to be integrated into the client's systems - especially with the websites as such, and also the web analytics system
• At the same time, it was necessary to adjust the appearance of the manager to match the visual style of the client

What we were Addressing

The primary intention was to use the tests during development. For this purpose, their architecture and operation (method of starting, reporting, etc.) were also designed. However, after development has been completed, the requirement has come for the tests to be used for each deployment. Put simply, for each release being prepared on another site / market, the solution had to be tested before launch and then after launch on production. This meant modifying the tests and parameterizing them via the command line.

After a while, another change followed, when it was decided that the release will not take place only for one website / market, but will be performed in bulk, for example for five websites or markets. At this point, it was no longer realistic to run tests that are strongly parameterized manually via the command line, but it was necessary to quickly create and start using a CI server.

Finally, we tuned the testing to a state where a parameterized test job is created on the CI for each deployed website or market. These jobs runs in a test environment. When deployed to production, the test job clone with a slightly different configuration handles tests for a given production site.

What we Tested With

Since almost all development takes place in JavaScript, we tried to find a suitable testing framework in this language. The framework also had to be able to directly provide or mediate interaction with the web, the data layer and the browser's network communication.

Finally, we chose wedriver.io. It is a very robust JavaScript framework that integrates Selenium - interaction with the web, Puppeteer (allows to capture network traffic of the browser). It provides methods for easy access to browser window objects (data layer). And last but not least, it supports Page Object Pattern in creating tests, which we have been using in this project.

The CI server is Jenkins, we have an instance of it running on the Google Cloud Platform. The Allure plugin in Jenkins takes care of reporting.

How it Ended Up

The Consent Manager has been successfully integrated into the client's systems and has been deployed for several months on websites across the markets where the client operates.