Automation of SIT Tests in the Development and Deployment of a Consent Manager on Web Platforms of a Multinational Company
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.
What it Will be About?
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
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.