Data Shield

Verify data has not changed, or is within thresholds

With Data Shield, part of TestShield, you can be sure configuration and reference data has not been altered since setup, and that system data stays within the thresholds you define.

Assemble. Arrange. Act. Assert.®

Setting up a Data Shield test follows the same four A’s pattern as every TestShield test.

1
Assemble
Describes the data that you are testing.
2
Arrange
Not usually needed for Data Shield: the data being checked is already in the system.
3
Act
Define the threshold checks, such as counting records or finding minimum and maximum values.
4
Assert
Define the data being checked, or the thresholds it is measured against.

Data Shield tests run manually, as part of an automated Test Runner schedule, or from Azure DevOps.

Two worked examples

Regulated data: authorised master trusts

The list of authorised master trusts a pension transfer is validated against is captured as the data under test, and the assert checks every entry by name and by record. A trust renamed, removed, or quietly added shows up on the next scheduled run, rather than in a transfer validated against a list that has moved underneath it.

The Assemble sheet of a Data Shield test named Active Authorised Master Trusts, under a Pension Transfer test plan: a Gherkin scenario reading, as the CRM administrator I want to ensure the authorised master trusts used by the pension transfer process are not changed, so that pension transfer requests are always validated against the correct list of authorised schemes. — Assemble

The Assert sheet of the same test: AssertAreEqual rows covering the authorised master trusts one by one, from Aegon and Aviva through NEST, NOW Pensions, Scottish Widows and Standard Life DC, each paired with its record. The first row is a deliberate negative case labelled not an authorised master trust. — Assert

Reference data: dental treatments

The list of active dental treatments is captured as the data under test, and the assert checks every row of it: name, code, treatment type, and whether it is charged per tooth. A row edited or quietly removed shows up on the next scheduled run, rather than in a claim.

The Assemble sheet of a Data Shield test named Dental Insurance, Active Treatments: a Gherkin scenario reading, as the CRM administrator I want to ensure the active treatments in the system are not changed, so that the data in the system remains consistently categorized. — Assemble

The Assert sheet of the same test: eighteen AssertAreEqual rows covering dental treatments from crown re-cement to single-tooth x-ray, each checking the treatment name, its record, its code, its treatment type and whether it is charged per tooth. — Assert

The other two shields

Back to the TestShield overview →

See Data Shield on your own processes.

Book a demo, or send us the process you most need protected.

Request a demo Get a free proof of concept