Everything an application remembers — users, orders, products — lives in a database. The UI shows only part of it, and may show it incorrectly. To verify that data was actually saved and saved correctly, a tester looks directly into the database. The language for talking to a database is SQL.

Don't be intimidated: to check data, you don't need to know everything. A few simple read queries are enough. Let's go through the essentials using an online store as an example.

What a database and tables are

A database is most often organized as a set of tables — like sheets in a spreadsheet. Each table has columns and rows. For example, a users table with columns id, name, email, and an orders table with columns id, user_id, amount, status.

A tester usually only reads data (looks at what's in the tables) rather than changing it. A read query starts with the word SELECT.

SELECT: display data

The basic query — "show these columns from this table":

SELECT id, name, email FROM users;

This means: "show columns id, name, email from the users table." An asterisk * means "all columns":

SELECT * FROM orders;

For now this just "dumps the table on screen." Next — how to select only what you need.

WHERE: filter the rows you need

WHERE is a filter — "show only the rows where the condition is true." The most common thing a tester does: find a specific record in the database that they just created through the UI.

SELECT * FROM users WHERE email = 'anna@example.com';

"Show the user with this email." You registered on the site — you run this query — you confirm the user actually appeared in the database with the right name.

Conditions can be combined:

SELECT * FROM orders WHERE user_id = 42 AND status = 'paid';

"Paid orders for user 42." This is how you verify that after payment the order's status in the database actually became paid and didn't stay as new.

A couple more useful things

  • Row count: SELECT COUNT(*) FROM orders WHERE user_id = 42; — "how many orders does user 42 have?" Handy for checking that exactly one order was created, not two (a common double-click bug).
  • Sorting: ORDER BY created_at DESC at the end — "newest first." Helps you quickly find a record you just created.
  • JOIN (linking tables). Data is spread across tables: an order stores user_id, but the user's name lives in the users table. JOIN combines them so you can see both together: "orders along with the buyer's name." This is slightly more complex — for now it's enough to know it's possible and look up the syntax when you need it.

You don't need to memorize the commands — they're easy to look up. The important thing is to understand the idea: data lives in tables, SELECT ... WHERE retrieves what you need.

Be careful with the production database

Three safety rules:

  • Work with the test database whenever possible, not the production one (where real users live).
  • A tester almost always only reads (SELECT). Commands that change data (UPDATE, DELETE) should not be touched without a clear reason and understanding — you can corrupt data.
  • If you only have access to the production database, be especially careful and don't run anything you're not sure about.

Where this applies

SQL turns checking from "it looks right on screen" into "it's definitely right in the database." You created an order — you verify it's in the database, just once and with the right amount. You paid — you confirm the status changed. You deleted something — you check the record is gone (or marked as deleted). This is grey-box testing in action and a skill that noticeably raises your value as a tester.

Where beginners stumble:

  • Trusting only the UI. The screen says "order created," but in the database it wasn't saved — or was saved twice — and you can only see that with a query.
  • Being afraid of SQL as "programming." In practice, SELECT ... WHERE is all you need for most checks — and it reads almost like plain English.
  • Changing data in the production database with an accidental command. Read (SELECT), don't modify without a clear reason.

What to learn next. If SQL is entirely new to you, take the SQL from scratch series: eight articles from tables and SELECT to transactions and indexes, no prerequisites (it forms a separate phase of this program). Then — cross-browser and mobile testing.