Some Springs Last Several Years or about the SPRING Project

Project Features

The SPRING Project was based on the transition from the obsolete DWH (Data Warehouse) type to a new one, which met the requirements of the Austrian National Bank and the European Central Bank. Our role in this project was primarily managerial one. It involved coordination of individual system teams, deployment management and emerging defects.

Our advent and operation of the project took place in the years 2019-2021 (the last official release of the project was the 2021_010 release).

Composition of the Team

The following team members participated in the Project:

• Jiří Novák (Team Leader, UAT Test Manager)
• Jaroslav Novák (Defect Manager, UAT Test Manager)
• Klára Siegelová (2020 UAT Test Manager)
• David Sedláček (2020, help with Defect Management)
• Katarina Vavreková (Solutions Manager, help with FAT test phase)
• Katarina Szaboová (Defect Manager)

How to Make it to the Summer

Along with the change of the data warehouse kernel, it was also necessary to reconnect all subsequent systems to the new kernel so that errors in data calculation did not occur. The aim of the project was to unify the data of individual countries so that it was possible to process them within one central system.

The project was divided into two project phases:

• Phase 0 - have a "Landing Zone" (GBL - Group Base Layer) prepared for data sent by individual countries and their subsequent processing by the system through the existing data warehouse (GDP - Group Data Pool).
• Phase 1 - Transition to a new data warehouse (GDS - Group Data Store), gradual switching of successive systems to a new data warehouse while simultaneously checking data quality, gradual disconnection from GDP and its decommissioning.

Changes Right from the Start or Set up Your Reporting Yourself

We joined the project during Phase 0 and as the project was coming to its end, more members joined. At the same time as we joined the project, the decision came to migrate the existing system for managing tests and defects to a new system which the entire group was to be brought under. Therefore, one of our first tasks was to set up this system so that we would be able to manage the whole process (we are talking about tens of thousands of tests and thousands of defects within one deployment).

Because of the huge amount of input data and the large number of downstream systems, there was extensive testing of new structures as well as regression testing of each system before each production deployment. This required both a high level of individual team commitment and precise and rapid coordination of defects and data processing schedules of individual countries by the entire system.

Systems, Bottlenecks and Snags with the Test Plugin

Atlassian JIRA was used to monitor defects with the TM4J (Test Management for JIRA) plugin to manage test scenarios, cycles and executions. We were not able to influence this choice, so we worked with what we had.

To divide the tests and cycles, there was a directory structure in the system where we sorted the tests based on to the individual systems. Thus, each end system had its own test cycle for FAT and UAT testing. For reporting purposes, it was then possible to combine all cycles into one test plan for a given release:

However, the test plugin lacked a number of features that we tried in vain to communicate with its vendor.

 Among one of the most important ones belonged inability to search for defects according to a cycle in which they were based. However, we were able to discover a workaround in the form of a static report that allowed us to extract defects in .csv form and then use them to search the JIRA instance. With an external vendor, we also negotiated a training program that makes it possible to edit larger amounts previously recorded test scenarios at once, which greatly facilitated the work.

Since both the IT and business users were involved in the testing, we decided to take the simplest possible approach for both parties in test execution as well as defect entry.

 The communication between the base JIRA instance and the test monitoring plugin was not in an ideal state (Defects had to be entered in a specific way to ensure a proper link with the test scenario and the original requirement the scenario was based on). Therefore, we had to train all users on how to use the system to prevent incorrect defect entry as much as possible and to facilitate overall management.

Working with Defects

Due to the fact that several systems were involved in the project, several fields had to be filled in when entering defects, which helped with subsequent sorting and organization (as mentioned above, searching for defects by cycle only was simply not possible). For this purpose, we have introduced several fields defects in  to facilitate this work:

Tenant - Identification of the data affected by the defect

Solution - Identification of the system in which the defect was found (the field did not change during the defect lifecycle)

Component - Indication of the system currently dealing with the defect (if the defect was detected in the last endpoint system, it was possible that the defect itself was located in its parent system)

Test Phase/Level - An indication of what phase of testing the defect was identified in (For FAT and UAT phases, there were additional specific levels depending on how the data was tested)

Ping-Pong Game

One of the issues we encountered was the frequent "swapping" of defects from one system to another to complete information. The defect status "Info Needed" was used for this purpose. We implemented a set of rules for defect resolution communication that helped to resolve the defect entries faster:

Summer Is Just Around the Corner

Thanks to the dedication of the entire team and all project members, we achieved the final deployment of SPRING into a production environment without delay in January 2021. The project will continue to undergo changes and maintenance. During the individual deployments, it was possible to observe how the defect resolution time and thus the total number of unresolved defects has gradually decreased. Two primary factors contributed to this: Both the existing users being familiar with the system and the incremental changes and improvements that we have been gradually adding to the system.