Where You Are Now
Some unit tests. Nothing enforces them.
That combination matters more than it sounds. Tests that do not block a merge are tests nobody maintains, because breaking them costs nothing. They drift, then get skipped, then get deleted in a cleanup. So regression confidence on n.tasc comes from experienced people remembering what is fragile.
That works until throughput goes up. And putting throughput up is exactly what this programme does.
What happens if you speed up without the net
Why this matters more for n.tasc than for most products
A defect in a CMS is embarrassing. A defect in a business-critical calculation produces a number a client acts on. A defect in a rule engine means a check that should have fired stays silent. In n.tasc the blast radius is a client's operations and regulatory standing, not a support ticket.
Three Layers of Net
Different problems. None replaces the others.
Where the effort goes, by layer
Golden Datasets for Critical Logic
The highest-value test asset here. Also the one that needs your domain owners most.
For anything that produces a number or a decision a client acts on — business-critical calculations, rule engines, thresholds and aggregations — unit tests are not enough. The hard part is not whether the code runs. It is whether the number is right.
How a golden dataset works
| Scenario family | What it pins | Why it earns its place |
|---|---|---|
| Core calculation path | Baseline arithmetic on the most-used flows | Everything hits this path constantly. A regression is wide and immediate |
| Multi-step calculations | Chained rules, offsets and derived values | The most intricate logic in the product. Easiest to break subtly |
| Cross-entity aggregation | Roll-ups across accounts, segments and groups | Aggregation bugs hide behind correct per-item results |
| Limit edges | Behaviour at, just under and just over a configured limit | Boundary handling is where threshold logic actually fails |
| Upstream integrations | Values derived from external and back-office inputs | Breaks for reasons outside the calculation engine |
| Degraded inputs | Stale data, missing upstream feed, partial input file, empty data sets, expired records | How the system behaves on bad input is a business decision, not an error path |
| Rule-trigger scenarios | Synthetic cases that must and must not trigger each rule | Proves alerts and checks still fire. A false negative is invisible until it is critical |
This is the biggest ask in the plan
Roughly two to three days of domain-owner time per scenario family. It cannot be handed to the agents, because the datasets exist to check the agents. If this time is not protected in weeks five to eight, Stage 2 slips and the pilot slips with it. We would rather flag it now than report it as a variance in week nine.
Test Data and Environments
The practical things that stall most testing efforts in this domain
No production data
- Synthetic client codes, accounts and transactions
- Recorded, replayable upstream data instead of a live feed
- Deterministic clocks. Behaviour depends on time of day
- Datasets versioned with the tests that use them
Real DB, throwaway instance
- Containerised database per pipeline run
- Real schema and migrations deployed, because that is where data rules live
- Seeded from a known baseline, torn down after
- Kills the “works on the shared test server” class of failure
Intraday time simulation
- Pre-open, continuous session, post-close, settlement
- Cutoffs and scheduled jobs tested at the boundary times
- Feed interruption and recovery mid-session
- Near impossible to test manually with any reliability
Coverage targets by zone
- Critical business logic: high, non-negotiable, plus golden datasets
- Integration / API: every endpoint hit at least once
- UI: critical journeys, not a percentage
- Peripheral legacy: characterization where touched, not everywhere
No single coverage number
A blanket target makes people write tests to satisfy the number, and spends the same effort on a settings screen as on a calculation engine. Targets are set per zone, weighted to where a defect actually costs something.
What Changes for QA
The role gets harder and more valuable, not smaller
QA time today
- Writing routine test cases by hand
- Running the same regression journeys, release after release
- Working out what actually changed before testing it
- Chasing developers for what a change was supposed to do
- Last line of defence, under time pressure, where being wrong is expensive
QA time after
- Reviewing generated cases, mainly hunting what they missed
- Owning the golden datasets and deciding what correct means
- Exploratory testing where automation is weakest
- Opening a UAT pack that already lists what changed and what to test
- Designing the test strategy rather than executing it repeatedly
“Testing is faster and more reliable” — concretely
The suite runs on every commit and blocks the merge. Test cases arrive with the change instead of after it. Critical logic is checked against a frozen reference. QA arrives at UAT with a pack telling them where to look. The speed comes from removing the repetitive part. The reliability comes from the parts that no longer depend on anyone remembering.