Do we have to build a rule set first?

No. The entry point is a regression test with no rule set at all: SQACE compares the current run with the last one and shows every change. You then grow the business expected/actual verification release by release, where it delivers the most value.

Do our testers need SQL for this?

No, the entry point works without SQL through the visual builder. For edge cases, the SQL action is available so experienced testers are not held back. Validate ad hoc, reuse, automate: the same test becomes a scheduled or CI/CD-triggered suite without a rebuild.

Why is this worth it when nothing is broken?

A single release rarely justifies a tool purchase on its own. The value is in the repetition: those who embed data testing across the organization secure every release with the same method and decide on defensible reports rather than gut feel. That is the argument for the strategic buyer.

Regression testing for data

Start on day one. Then expand.

Release verification is rarely an acute pain, but it recurs with every release. You start with regression tests and no rule set at all, and grow the business verification release by release. No big bang.

Trigger Recurring, every release. The argument for the strategic buyer who embeds data testing across the organization.

Request a demo How it works

The problem

Every release can quietly shift a correct result.

A new release changes a calculation, an interface or a rule. The pipeline keeps running, the numbers look the way they always do. Only weeks later does it surface that a value has been quietly off since the last deployment.

Manual spot checks and Excel comparisons no longer keep up as the release cadence rises, and they are hard to defend in an audit. What is missing is a repeatable check that sets every release against the last one and against the expected business result.

Adoption without a big bang

Start small, expand release by release.

You do not have to build a rule set before SQACE delivers value. The entry point is a regression test, everything else grows step by step.

First regression test on day one, with no rule set at all.

01
Regression

Start immediately, no rule set. SQACE compares today's run with the last one and shows every change.
02
Rule sets

Author business rules in the visual builder, without SQL. SQL is available for edge cases.
03
Expected/actual

The expected result as a second, rule-based calculation, set against the actual, deviations classified down to field and rule level.
04
Automated

Grow the ad-hoc run into a scheduled, CI/CD-triggered suite in minutes.

Approach

Set the current release against the expected result.

Once a rule set is in place, SQACE checks not only whether something changed against the last release, but also whether the new release delivers the correct business result.

RUN RELEASE-2.7-EXAMPLE, on-prem COMPLETED

SOURCE PostgreSQL JDBC, LOCATION On-Prem/EU-Cloud, ACCESS read-only, REST /api/v1/runs

gross_amount_eur Expected 10,000.00 Actual 10,000.00 verified

fee_rate Expected 0.0150 Actual 0.0150 verified

fee_eur Expected 150.00 Actual 149.97 deviation

Rule IF a fee is calculated, THEN fee = gross_amount * fee_rate, rounded to two decimals. In the actual run, release 2.7 truncated instead of rounding.

Expected is the second, rule-based calculation, independent of the changed release code. Classified as a rounding deviation in the fee_eur field, since release 2.7, tracked across runs.

Run reproducible, versioned, in the audit trail. Security and architecture

Illustrative example, synthetic values

For the test engineer

Start without SQL, with SQL when needed.

Validate

Start without SQL

Expected values and rules are built in the visual builder and validated against real data before a run goes live. For edge cases, the SQL action is available.

Reuse

Build once, use often

A test building block that works is reused across releases and projects. What starts as an ad-hoc check stays in place without a rebuild.

Automate

From ad-hoc test to suite

The same test becomes a scheduled suite in minutes, or a CI/CD-triggered one via the REST API. Every release runs against the same method.

In practice

The ongoing verification, documented.

At LBBW, SQACE has been the central platform for data testing since 2020, from 6 productive applications, scaling toward 70 to 80. Documented publicly are, among others, 40% less effort in the data-testing lifecycle and 50% less effort to create test cases.

That is the effect of repetition: a standardized method that every release uses lowers the effort per run and makes release decisions defensible on solid reports.

40% less effort in the data-testing lifecycle, 50% less effort to create test cases, test runtime up to 90% shorter. Figures from LBBW, documented publicly on sqace.io.

LBBW, public reference (Jens Wauer)

Over 20 years of banking-domain depth (FINARIS, formerly RapidRep). Made in Europe, Frankfurt am Main.

Common questions

Release verification

Secure your next release.

In a demo we show the first regression test with no rule set, and how it grows into an automated suite. Or start with a proof of concept on a single pipeline.

Request a demo All use cases