PoC – Live operation brings certainty

Within the scope of a proof of concept (PoC), software solutions are tried out in a test run before purchase. The benefit: This can be done in a cost-effective practical manner. For this purpose – e.g. a PoC of the UBS Hainer TDM Suite – a functional TDM scenario is implemented at the prospective customer’s site. This allows the potential customer to experience in live operation what the TDM solution can achieve.

To allow this, the PoC is aligned with the realistic requirements of the customer. Depending on the requirements and scope, a concrete test strategy is developed for a clearly defined test area. For this purpose, the target criteria are analyzed and the most important key factors are identified. The entire process is advised and supported from beginning to end by the experienced UBS-Hainer developer team.

The goal is to make the features of the tool tangible in daily practice. This way, the customer can gather practical application experience and document the practicality. It is important that the PoC depicts the actual complexity of the application required by the customer as realistically  as possible. Based on the data obtained, the customer can make a realistic assessment of the feasibility and benefits of a full implementation.

Example: PoC at a large German insurance company

In 2019, the insurance company had set the goal of digitizing all processes. This also included automated test data procurement as part of software testing. Previously, it was the responsibility of the individual testers to define the required data and request it from the DBA. This was quite laborious and time-consuming.

The basic data had already been obtained by a UBS Hainer product – the BCV5 copy tool. This data was then used to perform ad hoc provisioning of corresponding tables into a test environment as needed. Now they wanted to automate the entire test data provision and to this end decided to perform a PoC.

This involved the database level, which was to be tested realistically. Among other things, the insurer had tables in which only personal data was stored. These were mostly customer tables, but also other people with whom the company interacted.

For example, in the case of the customer table, there was the customer header table and, in addition, around 20 sub-tables with detailed information such as account details, addresses, date of birth, contact data, relationships with other people, such as children, etc. A complex but daily relevant initial situation.

The task to be solved by the PoC was to consistently copy these tables with – in this case – seven sub-tables. In the process, anonymization was to be carried out when providing certain data. In the context of the PoC, the first name, last name, bank data, telephone number and e-mail address were changed in order to  create consistent, GDPR-compliant test case data.

These processes were implemented live at the customer’s site as part of the PoC. They corresponded to the challenges that later – after the order had been placed – led to two major project strands, namely data masking and test data provision.

The PoC was successfully completed and the major German insurer decided to implement UBS Hainer TDM Suite as part of its “Go Digital Strategy”.

If you are interested in a proof of concept for your company and would like to try out the TDM Suite at your company, please feel free to contact us at any time.

CURRENT POSTS

TDM Solution – Make or Buy?

The TOP5 ARGUMENTS why developing your own test data management solution is no longer profitable today. TDM has become a complex issue. For this reason, there are experts today who offer mature TDM solutions to the market

Read more »

Test data procurement – Three basic options

In the process of software development, tests need to be performed repeatedly. Depending on the stage of development, various test data, from individual test case data to bulk data, is required. There are three basic options for obtaining this test data: The manual creation of test data, the creation of synthetic test data and the conversion of productive data into test data

Read more »

Bulk data for system and release tests

Best-Practice: Test data procurement in the context of continuous software development (PART 3/3). Before the new or modified applications go live, system, release, load or performance tests are applied. For this purpose, no fine-grained customized test case data is needed, but production-related data in larger quantities is required. These tests are

Read more »

Customized test case data for functional, component and regression testing

Best-Practice: Test data procurement in the context of continuous software development (PART 2/3). The further development of an application usually means that different features or even bug fixes need to be implemented. Ideally, each feature gets its own environment. This environment contains only the relevant data for that particular case.

Read more »

Green light for automated
Test Data Management

Take advantage of our free initial consultation to quickly and easily determine your optimal and individual options!

Green traffic light