6pack test data management features include generation of synthetic data, transfer of test data between environments, maintenance of test data to keep them current (e.g. updating attributes that require to be updated recently) and cleaning or deletion of the test data.

6pack relies on generators that are written by developers or testers who are maintaining the systems under test. They can choose whatever method that is easiest to them. This includes direct inserts into databases of any kind, internal test data API calls that would not be available externally and then any external triggers such as public API calls or even UI automation.

6pack offers SDKs in various languages and some example generators for most common strategies, such as database insert. For those common strategies, the SDK offers helper functions / frameworks to simplify writing of the final generators to minimum. But the full flexibility of the selected native programming language is there as well.

In modern distributed services, things are changing very fast. Instead of constantly updating the test data catague and the related database model centrally, it is wiser to decentralise the logic to development teams. Those can chose whatever method to insert data: database insert, test data API call or even UI automation.

In cases where the best way how to get data to the systems under test is simulating user interaction, 6pack is compatible with any UI automation frameworks. This allows to reuse automated tests that you might already have. We also offer generator examples based on the test automation framework [Pumpo5](https://pumpo5.dev) that allows to automated web and mobile based on a page object pattern written in Java with under-the-hood Selenium, Selenide, Appium and more. Here comes one of the biggest advantages of 6pack: data generated in advance. Indeed, UI automation is always slower than API or database inserts: Having data prepared in advanced is a huge time saver for everybody.

Besides inserting data in target systems under test, which is done by generators, there is a lot of logic around; exposing a self-service portal, generating data in advance, handling retries and handling orchestration when several generators need to contribute to a single data set. 6pack does all that test data management for you while you are flexible to use your teams' domain specific knowledge.

No, 6pack handles pure synthetic data with no relationship to production data. A generator could theoretically use statistical information from production to generate data but this would not be a 6pack requirement. Inputs to the generator are configuration values that are either requested by testers, prescribed by some declarations in the generators themselves or invented using pure math. There are generators that can be responsible to transfer some metadata from one environment to another but again, this is not the general requirement.

Upon any generator being deployed on any test environment, it connects to 6pack and registers all data types that it can provision (generate in target systems under test). 6pack dynamically adjusts the UI and REST API based on those registrations. Each test environment is considered separately so 6pack autoconfigures itself as new data types are being made available on each test environment.

6pack tries to guess what data will be required and makes them generated in advance. The guessing algorithms are based on several inputs. One of the inputs can be simple declarations in the generators, another is based on historical trends. This way, test data are pre-ordered and once a tester needs them, there is no delay.

Test data is delivered either on the UI or using any type of notifications, such as emails or corporate chat platform. In fact, only test data references are delivered, which can only be a part of it. The remaining part stays in the target systems under test and is unknown to 6pack.

In case the tester needs test data with a configuration that has not been generated in advance, the generation request is sent ad-hoc to the respective generator(s). The dataset is then delivered when available.

6pack will retry generation indefinitely until success is achieved. Based on any failures in the meanwhile, some limited monitoring can be implemented. Based on per-generator configuration, 6pack can send alarms in case something does not work as expected.

Sharing data is not recommended. Each dataset, when delivered to a tester, is no more available to anyone else. This guarantees that each tester works with a specific set of data. The same applies to automated tests: each automated test will get a different dataset.

Generally speaking, not. All connections are from your infrastructure to 6pack and only test data references are shared with 6pack. The actual content of your test environments is not accessible from 6pack. What's more, synthetic data have the advantage of dummy data which imposes zero data protection issue.

This is not a recommended model, but it is available. 6pack can run in any K8S cluster and needs a simple SQL database.

6pack is free for small teams and affordable for the rest of them. Reach out for customized offer.

At [PumpITup](https://pumpitup.cz), we have been helping customers of all sizes to handle testing and test environment issues for years. We also focus on automation of any kind, such as CICD and IaC. 6pack is the result of our experience and fills the gap we see with almost each one of our client; how to do regression testing in complex environments without costly copying data from production and support the modern fast-pace decentralised development with true CI/CD.