Stop 05 · SQL & Databases for QATopics · 3/8

Database Testing Basics

In short

Every feature eventually becomes rows in a database. Database testing checks that create, update and delete actions in the app leave exactly the right data behind.

Verifying that data is correctly stored, retrieved, updated, and deleted — going beyond checking the UI to confirming the underlying database state actually reflects the expected outcome.

The purple blob stands beside an ATM machine, studying an open bank passbook closely.

Think of it like this

ATM screen vs passbook

The ATM says 'Rs 2,000 withdrawn'. But you only relax when the passbook shows the entry with the right amount and balance. Database testing is checking the passbook, not just the ATM screen.

Watch it happen

Following an order into the database

Tester

App

Database

Place order

1/5The tester places an order for 2 items through the app.

The big ideas

What you need to know

Create

After signup or an order, the right row exists with correct values and defaults.

Update

After an edit, only the intended columns changed, and updated_at moved forward.

Delete

Is it a hard delete (row gone) or soft delete (deleted_at set)? Check related rows too.

Sensitive data

Passwords should be hashed, never stored as plain text. Card numbers shouldn't be stored in full.

See it in code

Walk through the code

sql

1-- Create: after signup in the UI2SELECT email, status, created_at FROM users WHERE email = 'riya@test.com';3-- Update: after changing the phone number4SELECT phone, updated_at FROM users WHERE email = 'riya@test.com';5-- Delete: after "Delete my account"6SELECT deleted_at FROM users WHERE email = 'riya@test.com';

1/3The row exists, with status like ACTIVE and a fresh created_at.

One query per CRUD action. Run them right after doing the action in the UI and compare.

Save yourself the pain

Common mistakes

Oops

Only checking the main table after an action.

Do this instead

Check related tables too, like order_items, payments and audit logs.

Oops

Testing against production databases.

Do this instead

Use test databases. Production queries can slow the live app or expose real customer data.

Your mission

Trace a signup

~30 min

Quick check

A user deletes their account. The row still exists but deleted_at now has a timestamp. What is this?

Go deeper

1Design a test scenario verifying database state changes correctly after a UI action.
2Learn why relying solely on UI verification can miss data-layer bugs entirely.
3Practice checking database state before and after a test action to confirm the change.