The blocker nobody budgets for
Bad or missing data stalls more test runs than bad code. Qventis One makes the right record available before every run.
Test data engine
Stop losing test runs to bad data
Each run gets its own reserved, masked records, so parallel runs never collide and personal data never reaches a test environment.
- Records reserved per run
- Personal fields masked first
- No collisions in parallel
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
Each parallel run reserves its own records. Reservations expire, so a crashed run never holds data.
Safe by default
Personal fields are masked before data reaches a test environment, and secrets stay in your vault.
How the test data engine works
Pools that never collide
Many failures that look like bugs are bad data: a locked account, an order already refunded, a record another run took.
- 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
Can parallel runs share a pool?
Yes. Each run reserves its own records, so parallel runs never collide.
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.