For QA automation
Every edge case your suite needs, on demand and per run
Automated tests are only as good as the data behind them. DataNivra generates named business scenarios as synthetic, relationship-safe datasets, so each run gets the failed payment, the frozen account or the denied claim it asserts on.
The problem
Flaky suites are often a data problem: the record a test expects was changed or deleted by another test.
- The interesting cases — declined cards, chargebacks, delinquent loans — are rare in production and hard to find in a copy.
- Parallel suites share one environment and mutate each other’s rows.
- Negative tests need deliberately broken data that nobody wants in a shared database.
Live sample — synthetic, runnable now
These rows come from the published Financial Services bundle: invented records, generated from a fixed seed, with every key intact.
payment_id | payment_rail | amount | status | failure_reason |
|---|---|---|---|---|
| 1 | ZZ_WIRE | 680.32 | FAILED | BENEFICIARY_ACCOUNT_INVALID |
| 2 | ZZ_BATCH | 1221.60 | COMPLETED | — |
FS_EVERYDAY_BANKING— Ordinary customers, accounts, cards and activityFS_FAILED_PAYMENTS— Outgoing payments that fail or are returned, each with a failure reasonFS_DUPLICATE_TRANSACTIONS— Transactions re-submitted with identical content under new ids (double posting)FS_UNUSUAL_SEQUENCES— Bursts of sub-unit probe transactions seconds apart followed by a large spendFS_ACCOUNT_STATUS_CHANGES— Accounts moving to frozen, dormant or closed with a recorded change timeFS_CHARGEBACKS— Charged-back card transactions with chargeback dispute cases
Run it yourself
Count the failed payments by reason in the Financial Services bundle — the cases a payment-retry test asserts on. Python 3, standard library only.
import csv, io, urllib.request
from collections import Counter
URL = "https://www.datanivra.com/downloads/packs/financial-services/2.1.0/synthetic/payments.payments.csv"
with urllib.request.urlopen(URL) as response:
rows = list(csv.DictReader(io.StringIO(response.read().decode("utf-8"))))
failed = Counter(r["failure_reason"] for r in rows if r["status"] == "FAILED")
print(f"{len(rows)} payments, {sum(failed.values())} failed")
for reason, count in sorted(failed.items(), key=lambda kv: (-kv[1], kv[0])):
print(f"{count} {reason}")Expected output:
11 payments, 4 failed
2 BENEFICIARY_ACCOUNT_INVALID
1 ACCOUNT_CLOSED
1 LIMIT_EXCEEDEDFull tested example: Banking test scenarios — failed payments, chargebacks and frozen accounts. Or open the synthetic playground for this pack — no account.
The outcome
- Each test names the scenario it needs; the dataset is generated for that run and thrown away afterwards.
- Negative-test scenarios are labelled as broken on purpose and never mixed with valid data.
- Cross-table links survive generation: a chargeback points at a real transaction, a card at a real account.
- Pipelines can require a dataset that passed your configured policy gates before the suite starts.
Security: production data stays home
Runs in your environment Row-level work happens only in your environment.
- Scenario data is synthetic: it starts from pack templates, not from customer records.
- When scenarios are seeded from your own systems, row-level work stays in your network and only aggregate evidence is reported.
- FAILED or REVOKED datasets are never provisioned to a test environment.
Customer-resident architecture · Verify it yourself · Security model
Your first action
- Preview the Financial Services scenarios in the synthetic playground.
- Run the banking scenarios page to see failed payments, chargebacks and a frozen account linked by key.
- Start free to request scenario datasets per run from the console or the CLI.
Other teams: Developer · Data engineer · Platform engineering · Healthcare · Finance · Insurance · Manufacturing · All teams