Database & Backend Testing — Verifying the Persistence Layer
The UI can say “saved” while the database stored nothing, the wrong thing, or a half-written mess. This track teaches you to test what the screen cannot show you.
Most testers stop at the interface. They click a button, see a green tick, and move on. But the screen is the last place a data defect shows up — and often it never shows up at all. An orphaned row, a migration that dropped a column, a debit that posted twice in the ledger: these live in the persistence layer, behind the UI, where a screenshot cannot reach. This track teaches you to query the database directly, prove that an action persisted correctly, and catch the silent-corruption defects that pass every UI test.
From your first SELECT to safe test data
SQL for Testers
SELECT, JOIN, WHERE, and GROUP BY to assert state. Proving a UI or API action actually persisted. Reading a schema you have never seen. The NULL traps that quietly break your queries.
~30 min read · ~70 min with exercises · Database Testing
Lesson 2Data & Referential Integrity
Constraints, foreign keys, and uniqueness. Orphaned rows and cascade deletes. The silent-corruption defect class — the data damage that no error message ever announces.
~30 min read · ~70 min with exercises · Database Testing
Lesson 3Migration & Schema-Change Testing
Backward compatibility and data preservation. Rollback and zero-downtime migrations. Row-count and checksum reconciliation — proving every row arrived intact on the other side.
~30 min read · ~75 min with exercises · Database Testing
Lesson 4Test Data Management & Masking
Synthetic data design and anonymisation. De-identification under the Privacy Act 2020 and Privacy by Design. Refreshing non-production data safely, without leaking a single real customer.
~30 min read · ~70 min with exercises · Database Testing
The screen is not the system of record
A tester who only tests the UI is testing a story the application chooses to tell. The screen says the KiwiSaver contribution was recorded, the address was updated, the claim was lodged. But the screen is a rendering, not the truth. The truth sits in the database, and the two can disagree in ways no click ever reveals.
The defects that hurt most in NZ systems are persistence-layer defects. A payment that debits twice in the ledger but shows once on screen. A customer merge that orphans every linked policy. A migration that silently truncates IRD numbers. A non-production refresh that copies real customer data into a system with weaker controls. None of these throw an error. None of these fail a UI test. They are caught only by someone who can query the data directly and reconcile it against what the action claimed to do.
This track builds that ability from the ground up. You start by learning to assert state with SQL, then move to integrity and the silent-corruption defect class, then to migration testing where whole tables are rewritten, and finally to managing and masking test data lawfully under the Privacy Act 2020. By the end you can prove — with a query and a reconciliation, not a screenshot — that the system recorded what it said it did.
Other specialised tracks
API Testing
Testing the layer between the UI and the database — contracts, status codes, and payloads.
TrackBanking QA
Ledgers, payments, and reconciliation — where persistence-layer correctness is money.
TrackPrivacy Testing
Testing for compliance with the NZ Privacy Act 2020 across the systems that hold personal data.