Database Testing Interview Questions for Software Testing
30 Database Testing questions with answers for software testing roles — 7 easy, 13 medium, 10 hard.
About Database Testing
Database testing questions check whether you can confirm what the application really stores, not just what the screen shows. Interviewers ask about data integrity, keys and constraints, stored procedures, triggers, transactions, schema changes and SQL validation queries. Strong answers show you can write a quick query to prove a bug, reconcile data after loads and protect sensitive data in test environments.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
Database testing checks that the data an application stores and reads is correct, complete and safe. It covers schema checks (tables, columns, data types), constraints and keys, data integrity after create, update and delete actions, stored procedures, triggers and views, transactions, and basic performance of heavy queries. For example, after placing an order in the UI, a tester queries the orders and order_items tables to confirm every value was saved exactly as entered.
02
How is back-end database testing different from front-end UI testing?
UI testing checks what the user sees and does: screens, buttons, messages and flows. Database testing checks what happens underneath: whether the right rows are inserted, updated or deleted, whether constraints hold and whether data stays consistent across tables. A screen can show a success message while the database saved a wrong amount or nothing at all. So testers combine both, using SQL to confirm that every important UI action leaves the database in the expected state.
03
SQL: how do you test that a primary key rejects duplicate values?
-- Insert a row, then try the same key again; the second insert must fail
INSERT INTO users (id, email) VALUES (9001, 'a@test.com');
INSERT INTO users (id, email) VALUES (9001, 'b@test.com');
-- Expected: duplicate key or unique constraint error
SELECT COUNT(*) FROM users WHERE id = 9001;
-- Expected: 1
DELETE FROM users WHERE id = 9001;
04
What is a database view and what do you verify when testing it?
A view is a saved query that behaves like a virtual table, often used for reports or to hide sensitive columns. When testing it, compare its output with the same query run on the base tables, check filters and joins return the right rows, confirm hidden columns such as salary are really absent, check behaviour when base data changes and verify that users without permission on the base tables can still read the view if intended.
05
SQL: find rows where mandatory columns are NULL or empty in a customers table.
-- Mandatory fields: name, email, phone
SELECT id, name, email, phone
FROM customers
WHERE name IS NULL OR TRIM(name) = ''
OR email IS NULL OR TRIM(email) = ''
OR phone IS NULL OR TRIM(phone) = '';
-- Expected result: no rows
06
SQL: find orders that have an order date in the future.
-- Orders cannot be placed in the future
SELECT id, order_date, status
FROM orders
WHERE order_date > CURRENT_TIMESTAMP;
-- Expected result: no rows. If rows appear, check time zone handling and input validation.
07
What is data masking and why is it used in test databases?
Data masking replaces real sensitive values with realistic but fake ones, for example changing real phone numbers to valid-looking dummy numbers and real names to generated names. It lets teams test with production-like data volume and patterns without exposing customer information. It also supports compliance with India's Digital Personal Data Protection Act. Testers should check that masked data still passes validation rules and keeps relationships between tables intact.
08
What is data integrity and what are its main types?
Data integrity means data stays accurate and consistent through its life. Entity integrity: every row has a unique, non-null primary key. Referential integrity: a foreign key always points to an existing parent row, such as every order pointing to a real customer. Domain integrity: values stay within allowed types and ranges, enforced by data types, CHECK and NOT NULL constraints. User-defined integrity covers business rules, such as an order total never being negative.
09
SQL: how do you test a foreign key defined with ON DELETE CASCADE?
-- Create a parent and child, delete the parent, child rows must disappear
INSERT INTO customers (id, name) VALUES (501, 'Cascade Test');
INSERT INTO orders (id, customer_id, total) VALUES (7001, 501, 250);
DELETE FROM customers WHERE id = 501;
SELECT COUNT(*) FROM orders WHERE customer_id = 501;
-- Expected: 0
-- Also test inserting an order for a non-existent customer: it must fail
10
What are ACID properties and how can a tester check them?
ACID means Atomicity, Consistency, Isolation and Durability. Atomicity: a transfer that debits one account must also credit the other, or neither happens; test by forcing a failure midway. Consistency: constraints still hold after the transaction. Isolation: two users updating together do not see each other's half-done work; test with two sessions. Durability: committed data survives a restart; test by committing, restarting the service and querying again.
First read what the trigger should do and when it fires, such as AFTER UPDATE on the salary column writing a row to an audit table. Then perform the event that should fire it and query the target table to confirm the expected row and values. Also perform events that should not fire it and confirm nothing happens. Check multi-row updates, NULL values and rollback: if the main statement fails, the trigger's changes must not remain.
Data mapping testing checks that each field on a screen, file or API goes to the correct table and column with the correct format. For example, the Date of Birth field on the signup form must land in users.dob as a date, and the State dropdown must store the state code, not the label. Testers use a mapping document, enter known values in the UI or API and query the database to compare field by field.
13
SQL: verify that row counts and totals match between a source table and a target table after a data load.
-- Compare counts and sums side by side; both columns must match
SELECT
(SELECT COUNT(*) FROM staging_orders) AS src_count,
(SELECT COUNT(*) FROM dw_orders) AS tgt_count,
(SELECT SUM(amount) FROM staging_orders) AS src_amount,
(SELECT SUM(amount) FROM dw_orders) AS tgt_amount;
14
SQL: check that no user has more than one active subscription.
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
15
What is normalization and why should a tester understand it?
Normalization organises tables to reduce duplicate data, for example storing the customer address once in a customers table instead of repeating it in every order. Testers should understand it because it explains where data lives and which joins are needed to verify a screen. It also shows risk: in a denormalized report table, the same value is copied in many places, so updates must be tested to confirm every copy changes.
16
A user updates their phone number in the app, but the old number still appears in reports. What do you check?
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
17
A report shows duplicate rows after a new release. How do you investigate in the database?
Run the report query with GROUP BY on the business key and HAVING COUNT(*) > 1 to find which records repeat. Then check whether the duplicates exist in the base table or are created by the query, usually a new join to a one-to-many table such as addresses. Compare the query before and after the release. Include the duplicate keys, the count and the suspected join in the bug report.
18
A form saves names with an apostrophe, like O'Brien, incorrectly or fails to save them. What do you test?
This suggests the input is not handled safely, possibly string-built SQL, which is also a SQL injection risk. Test names with apostrophes, double quotes, Hindi and other Unicode text, emojis, leading spaces and maximum length. Query the database to confirm the exact stored value and character encoding. Then check the value displays correctly everywhere it is read back. Log a high-severity bug and mention the possible injection risk.
19
How do you set up and clean test data for database tests without affecting other testers?
Create your own data with a clear prefix or tag, such as emails starting with qa_ravi_, or IDs in a reserved range. Insert data through the app or API where possible so it follows real rules, and keep SQL setup scripts in version control. After testing, delete only your tagged rows, or run inside a transaction and roll back. Never edit shared master data without telling the team.
20
Tell me about a time you found a bug by checking the database directly.
Situation: a wallet refund screen showed success for every test. Task: I wanted to confirm the balance logic. Action: I queried the wallet_transactions table and saw two refund rows when I double-clicked the submit button, though the UI showed one. I logged it with both query outputs and the steps. Result: developers added an idempotency key, and the team added a database check to our regression checklist.
21
What is a stored procedure and how do you test it?
A stored procedure is a named block of SQL logic saved in the database and called with parameters, for example a procedure that calculates monthly interest. To test it, call it with valid, boundary and invalid inputs, check the returned values or result sets, verify the rows it inserts or updates, check error handling for bad parameters and confirm it rolls back on failure. Also check its run time with realistic data volumes.
22
What is ETL testing and how does it relate to database testing?
ETL testing validates data that is Extracted from source systems, Transformed by business rules and Loaded into a target such as a data warehouse. It is a specialised form of database testing. Checks include source-to-target row counts, transformation rules such as currency conversion, handling of NULLs and duplicates, rejected-record logs, incremental loads that pick up only new changes and reconciliation of totals between source and target.
23
During a load test, some booking requests fail with a 'deadlock detected' error. What is happening and how do you report it?
A deadlock happens when two transactions each hold a lock the other needs, so neither can continue. The database detects it and kills one transaction with an error. During testing it usually appears under concurrent load, for example two users booking the last seats at once, as random failures or 'deadlock detected' entries in logs. Testers report the exact actions and timing, and developers fix it with consistent lock order or shorter transactions.
24
What are transaction isolation levels and what is a dirty read?
Isolation levels control how much one transaction can see of another's uncommitted work. Common levels are Read Uncommitted, Read Committed, Repeatable Read and Serializable. A dirty read is reading data another transaction changed but has not committed; if it rolls back, you acted on data that never existed. Testers check isolation using two database sessions: update without committing in one and query in the other to see what is visible.
25
How do you test concurrent updates to the same record, such as two agents editing one ticket?
Open the same record in two sessions, change different fields and save both, then change the same field and save both. Check the database to see which value won and whether data was silently lost. A good design uses optimistic locking, where the second save fails with a 'record changed, please reload' message because a version column changed. Also repeat with API calls fired together to catch timing issues the UI hides.
26
A security reviewer asks you to confirm that passwords and personal data are stored safely. What do you check in the database?
Query the users table after signup and confirm the password is not stored in plain text or reversible encoding, but as a salted hash from a slow algorithm such as bcrypt or Argon2. Two users with the same password should have different hashes. Check that card numbers are not stored at all or are tokenised, that personal data like Aadhaar numbers is masked or encrypted, and that logs and audit tables do not copy the raw values.
27
How do you verify database schema changes in a new release?
Get the migration script or change list. Compare the schema before and after: new tables and columns, data types, lengths, default values, NULL rules, indexes and constraints. Check that existing data was migrated correctly, for example a new status column filled for old rows. Run the main app flows to confirm queries still work. Finally, confirm the rollback script works on a copy, so the release can be reversed safely.
28
Your team says nightly database backups are working. How do you prove that a restore actually works?
Take a backup of a test database with known data, record row counts and a few checksums, then restore it to a separate server. Compare counts, sample records, constraints and users. Measure how long restore takes against the recovery time objective, and check that point-in-time restore loses no more data than the recovery point objective allows. A backup that has never been restored is not proven, so this test should run regularly.
29
How do you test time zone handling for timestamps stored in a database?
Check how timestamps are stored, ideally in UTC with a time zone aware type. Create a record from a user in IST and another in a different zone, then query the raw value and compare it with what each user sees on screen. Test boundaries such as orders placed just before midnight IST, which fall on the previous UTC date, and daylight saving changes for foreign users. Reports grouped by date are a common bug area.
30
A monthly report query runs on millions of rows and takes minutes. How do you test and report its performance?
Test on a database with production-like volume, not a small QA dataset. Measure the run time several times and note the filters used. Ask for or run the execution plan to see whether it does full table scans or uses indexes. Compare with the agreed target, such as under five seconds. Report the query, data volume, timings and plan, and retest after fixes such as indexes, date filters or summary tables.
Frequently asked questions
How important is Database Testing in Software Testing interviews?
Database testing questions check whether you can confirm what the application really stores, not just what the screen shows. Interviewers ask about data integrity, keys and constraints, stored procedures, triggers, transactions, schema changes and SQL validation queries. Strong answers show you can write a quick query to prove a bug, reconcile data after loads and protect sensitive data in test environments.
How should I use the Database Testing sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.