Database Testing interview questions
Database Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
You changed a customer’s address in the UI and the new value is on screen. Why would you still look at the database?
The strongest answer: The screen may be showing what I typed rather than what was stored — a SELECT on that row proves the value landed, in the right column, on the right record
Why it works: Right — the UI can render local state; the row is the evidence that a write actually happened.
- Trust the row, not the screen.
- SELECT the record you changed.
- Check the exact columns.
- Never hand-edit to “fix” it.
Someone offers a production database dump for local QA. What do you do?
The strongest answer: Refuse a raw dump — I want masked or synthetic data with a known setup, not real people’s records on a laptop
Why it works: Exactly. Prod data is other people’s lives. Mask or synthesise; do not souvenir a dump.
- No raw prod dumps.
- Mask or synthesise.
- Known setup beats “realistic mystery.”
- Never commit personal data.
A delete feature removes a customer. A week later, support reports odd rows in a report.
What do you check in the database?
The strongest answer: Whether child rows were left behind — join orders to customers and look for orders whose customer no longer exists — then ask whether the design wanted a cascade or a soft delete
Why it works: Exactly — orphaned children are the classic delete defect, and the fix is a design decision rather than a one-off clean-up.
- Look for the orphans.
- Join child rows to their parent.
- Find children with no parent.
- Ask: cascade, or soft delete?
Nightly tests fail because yesterday’s orders are still “open.” What is the data lesson?
The strongest answer: Tests must create and clean their data, or use isolated tenants — a shared dirty pool is not a fixture strategy
Why it works: Exactly. Isolated, created, cleaned. Shared leftovers are flakes dressed as data.
- Create what you need.
- Clean it up.
- Isolate tenants.
- Do not share a dirty pool.
CI needs “realistic” addresses. What do you use?
The strongest answer: Generated or clearly fake fixtures that still exercise validation — not a slice of last night’s prod export
Why it works: Exactly. Realistic shape, fake people. Prod slices are how CI becomes a leak.
- Synthetic, shaped like prod.
- No prod export in CI.
- Vary enough to hit rules.
- Do not use staff addresses.
The dashboard says 41 open orders. The nightly report says 42.
How do you find the difference?
The strongest answer: Compare the sets, not the numbers — list the ids each side returns and look at the rows only one of them has; the difference usually names the filter or the time window they disagree on
Why it works: Right — the differing rows tell you which status, filter or cut-off time the two definitions disagree about.
- Compare sets, not totals.
- List the ids from both sides.
- Inspect the rows only one has.
- Name the filter that differs.
A payment fails halfway through checkout and the user sees an error.
What do you check in the data?
The strongest answer: Whether the order, the payment record and the stock reservation still agree — an order marked paid with no payment row, or stock left reserved, means the write was not atomic
Why it works: Exactly — a partial write across tables is the defect, and naming the records that must agree is what makes the bug real.
- Failures must leave data consistent.
- List the records a flow writes.
- Check they agree after the failure.
- Capture the state before cleaning.
Every squad invents its own users and the suite collides. What do you build?
The strongest answer: A fixture service or a paved factory: isolated tenants, cleanup, and no shared god-user — I do not preach “just be careful”
Why it works: Exactly. Data is platform. Factories and isolation beat manners.
- Paved fixtures.
- Isolated tenants.
- Cleanup you can trust.
- No shared god-user.
A data migration moves years of customer records to a new schema on release night.
What does QA hand the go/no-go meeting?
The strongest answer: Row counts per table before and after, key aggregates reconciled to the same totals, a sampled row-by-row comparison including the ugly records, a rehearsed rollback — and what was not checked
Why it works: Right — counts, reconciled aggregates, sampled rows and a tested rollback, with the gaps stated, is a defensible sign-off.
- Prove the data, not the script.
- Compare counts and aggregates.
- Sample real and ugly rows.
- Rehearse the rollback.