SELECT is the query you will run 80% of the time as a tester. It reads data. It does not change anything. It is safe. Think of it like opening a file in read-only mode.
-- Get everything from the users table
SELECT * FROM users;
-- Get specific columns only (always prefer this in production)
SELECT first_name, last_name, email FROM users;
-- Count total rows in a table
SELECT COUNT(*) FROM users;Never run SELECT * on a production table with millions of rows. It can slow down the database and get you in trouble. Always add a WHERE clause or LIMIT when querying production data.
Register a new user through the UI with email test@example.com
Open your SQL client (DBeaver, pgAdmin, MySQL Workbench)
Run: SELECT * FROM users WHERE email = 'test@example.com';
Verify: first_name, last_name, email match what you entered
Check: created_at timestamp is recent (not null, not year 1970)
Check: status column is "active" or "pending" as expected
Check: password column is hashed, NOT stored in plain text
-- After registering user "Ravi Kumar" with ravi@test.com
SELECT
id,
first_name,
last_name,
email,
status,
created_at,
LENGTH(password_hash) AS pwd_hash_length
FROM users
WHERE email = 'ravi@test.com';
-- Expected: one row with correct data
-- password_hash length should be 60+ (bcrypt) or 64+ (sha256)
-- status should be 'pending' if email verification is requiredAlways check the password column. If you see plain text passwords like "password123" instead of a hash like "$2b$10$X8d...", that is a critical security bug. File it immediately.
Q: What is the difference between SELECT * and SELECT column_name?
A: SELECT * fetches all columns, which is convenient for exploration but wasteful in production — it transfers unnecessary data and can break if columns are added later. SELECT column_name fetches only what you need. In testing, SELECT * is fine for quick checks. In automated test scripts or production queries, always list specific columns.
Key Point: SELECT reads data without changing it. Always specify columns and use LIMIT on production databases.