The blocker nobody budgets for
A locked account or an order already refunded fails a run that has nothing wrong with the app. The right record is ready before every run.
Test data engine
Stop losing test runs to bad data
The test data engine runs on the Qventis Engine. Plain-English steps name a data set, and each run gets its own reserved, masked records, so parallel runs never collide and personal data stays out of test environments.
- Records reserved per run
- Personal fields masked first
- Any source, one syntax
Use data set 'Open orders' reserved for 30 minutes
Open the 'Back office' app
Type '{{orders.order_id}}' into 'Order search'
Click the 'Refund' button
Check that 'Refund total' shows '{{orders.amount}}'
Data that is ready when you are
No collisions
Reservations expire, so a crashed run never holds data another run needs.
Safe by default
Masking runs before data leaves production, and credentials stay in your vault.
How the test data engine works
Pools that never collide
Many failures that look like bugs are bad data. Pools and reservations take that off the table.
- Separate pools for dev, test and staging, picked by the run's target
- Each run reserves its records for a time limit you set
- Expired reservations release on their own
Realistic and safe
Take a small, consistent slice of production-shaped data, or generate records from rules.
- Subsetting keeps related records together
- Masking hides personal fields before data leaves production
- Synthetic rules such as "customers in Texas with two open loans"
- Optional AI rule suggestions, reviewed by a person
Bind any source
Name a data set once and refer to its columns as {{dataset.column}} in any step. The source can change without touching the test.
- CSV files versioned in Git, and Excel sheets kept by business testers
- Database queries for live records that match a condition
- Connects to Delphix, K2view or Tonic if you already use them
Data you can trace
Data sets attach to entities such as Customer, Order and Invoice in the App Model.
- Functional, performance and data tests draw from the same pools
- Every virtual user in a load test gets a distinct record
- Quality View records which data each run used, so you can tell an app fault from a bad record
Questions
Does synthetic data need AI?
No. Rules work without AI. Suggestions are optional, can be switched off per project, and a person approves them.
Does production data reach test environments?
Only if you bring it in, and personal fields are masked before it does.
See your flaky runs get clean data
Bring a suite that fails on data, and see each run get its own reserved, masked records.