SELECT retrieves columns from a table; WHERE filters which rows are returned by a condition. Together they are the foundation of every validation query a tester writes.
A SELECT statement names the columns you want (or * for all) and the table (FROM). WHERE restricts the result to rows matching a condition, using comparison operators (=, <>, >, <, >=, <=). For validation you almost always filter by a stable, unique key — a primary key id or a unique field like email — so the query targets exactly the row your test created, not a random match. Selecting only the columns you need (rather than *) makes the intent and the assertion clearer and avoids surprises when the schema changes. Being precise here matters: a validation query that returns the wrong row, or many rows when you expected one, produces a false pass or a confusing failure. String and date literals are quoted; numeric literals are not. Understanding case-sensitivity and exact-match semantics for your database prevents subtle mismatches.
After creating an order via API that returned id 5001, a tester validates it with SELECT status, total FROM orders WHERE id = 5001 — filtering by the exact primary key so the assertion targets that one order and nothing else.
-- All columns for one user (quick investigation)
SELECT * FROM users WHERE email = 'qa@qapractice.com';
-- Explicit columns for a precise assertion
SELECT status, total
FROM orders
WHERE id = 5001;
-- Numeric vs string literals
SELECT id, name
FROM products
WHERE category = 'Electronics' -- string: quoted
AND price > 100; -- number: unquotedScenario: A tester validates a newly created order with SELECT status FROM orders WHERE total = 59.98 and the assertion intermittently fails or passes against the wrong record. What is wrong with this query and how should it be written?