SQL for SDET, QA Tester and Manual Testers - Interview Questions and Answers

Here are my SQL Interview Questions and Answers for SDET, QA Tester and Manual Testers. Read the interview questions on Introduction to SQL for Testers, Basic SQL Concepts (databases, tables, rows, and columns, SQL Data Types, DDL commands, DML commands, Writing SQL Queries, Working with Joins and Multiple Tables, Intermediate SQL Concepts (Grouping data, Aggregate functions, Subqueries and Using UNION and INTERSECT) and Advanced SQL Concepts (Common Table Expressions, Window Functions, Creating and using VIEWS for testing, Indexes and performance tuning and Handling SQL transactions).

If you want my complete set of SQL Interview Questions and Answers as a document that additionally contain the following topics, you can message me on LinkedIn or send me a message in the Contact Us form in the right pane:
SQL in Different Database Platforms (Oracle, PostgreSQL, SQL Server and NoSQL Databases (MongoDB)), SQL Queries for Manual Testers, SQL in Automation Testing (Java, Python, etc.) and SQL for API Testing, SQL Queries for Performance Testing, Data Validation Using SQL, More SQL Questions for QA Interview Preparation and Writing SQL queries for real-world problem-solving in interviews, Scenario-based SQL questions, Best practices for SQL-based problem-solving in QA interviews, SQL Best Practices for Testers and Best practices for organizing SQL queries in testing projects and SQL Tips and Tricks for QA Testers.

Question: What is SQL? Why is it important in QA testing?
Answer: SQL (Structured Query Language) is a standard language used to interact with relational databases for storing, retrieving, and manipulating data. In QA testing, SQL is needed because testers need to validate the data stored in databases, verify data consistency, and test if the application’s backend is functioning correctly.
For example, when testing a web application, a tester may need to run SQL queries to find out if the data entered in the frontend is correctly saved in the database. QA testers frequently use SQL for:
- Verifying if CRUD operations (Create, Read, Update, Delete) are working as expected
- Validating reports or UI data against the database for accuracy
- Checking database constraints (e.g. unique keys, foreign keys) during functional testing.
Example: To verify that user data is correctly inserted into the users table after registration, a QA tester might run:

SELECT * FROM users WHERE username = 'john_doe';

SQL is needed in different testing approaches:
- Manual Testing:
a. Manual testers use SQL to manually validate if the data in the database is the same as what is shown in the application’s user interface (UI).
b. They can write SQL queries to check that new entries, updates, or deletions made through the UI are reflected correctly in the database. Example: After updating a user’s email address through the application UI, a manual tester may run the following query to verify if the email has been updated:

SELECT email FROM users WHERE username = 'john_doe';

* Automation Testing (SDET):
a. In automation, SDETs can write SQL queries within their test scripts to fetch and validate data directly from the database as part of automated test validation. Note that embedding SQL in UI-driven test scripts requires managing database connections and cleanup.
b. SQL can also be used to set up test data before executing test cases or to clean up after tests.
c. Example: In a Selenium test script, SQL queries might be used to verify database records:

- API Testing: Testers use SQL in API testing to validate that the data sent via API calls is correctly inserted or updated in the database. Example: After making a POST request to an API that creates a new order, a tester can run SQL to validate the order creation:

SELECT * FROM orders WHERE order_id = '12345';

Question: What is the difference between relational databases (SQL) and non-relational databases (NoSQL)?
Answer: Relational databases (SQL) and non-relational databases (NoSQL) differ in their structure, use cases, and data handling methods.
Relational Databases (SQL): SQL databases store data in structured tables with rows and columns. They use SQL queries to perform operations on the data. Data is organized in relations (tables), and each table has a predefined schema. In the example below, Customers, Orders, OrderDetails and Products are the tables. The Customers table has the columns CustomerID, FirstName and so on.
Relational databases are ideal for complex queries, transactions, and applications where data integrity is crucial (e.g. financial applications, ERPs). Examples: MySQL, Oracle, PostgreSQL, SQL Server.

Non-relational Databases (NoSQL): NoSQL databases store data in a flexible, schema-less manner, typically as documents, key-value pairs, or wide-column stores. They are suited for handling large volumes of unstructured or semi-structured data, such as JSON, XML, or blobs. NoSQL is used for applications that need scalability, like social media platforms or real-time analytics. Examples: MongoDB (Document-based), Cassandra (Wide-column), Redis (Key-value), Neo4j (Graph database).

Question: When should QA testers use SQL databases vs NoSQL databases?
Answer: It depends on the type of application, its data structure, and specific project requirements:
- SQL databases should be used when:
o Data integrity and ACID (Atomicity, Consistency, Isolation, Durability) properties are critical.
o There is a need for complex joins, relationships, and transactional consistency.
o The data is structured and has well-defined relationships (e.g. e-commerce sites, inventory management).
o Example: If a QA team is testing a banking application, a SQL database like PostgreSQL would be suitable due to the need for data accuracy, complex queries, and strong relationships between tables.

- NoSQL databases should be used when:
o The application requires high scalability and performance over large datasets.
o The data is semi-structured or unstructured (e.g. JSON, XML).
o There are no complex relationships or strict schema requirements (e.g., social media, IoT applications).
o Example: For testing a document-heavy application, like a content management system (CMS), a NoSQL database like MongoDB would be appropriate because of the flexibility in storing different document formats.

You can learn about various aspects of database testing including SQL in my Database Testing tutorials playlist (I’ve published 13 videos in it as of date) at https://www.youtube.com/playlist?list=PLc3SzDYhhiGVVb76aFOH9AcIMNAW-JuXE

Question: What are databases, tables, rows, and columns in the context of SQL?
Answer: In SQL, databases, tables, rows, and columns are components used to store and organize data. I’ve explained these components and shown examples in my Database Testing tutorial at https://youtu.be/W_fH6CqiTDU
- Database: A collection of organized data that can be accessed, managed, and updated. It acts as a container that holds tables and other database objects such as views, indexes, stored procedures and triggers.
- Table: A structured set of data that contains rows and columns. It represents a specific entity in the database, such as customers, orders, or products.
- Row (Record): Each row in a table represents a single, complete set of data (i.e. a record) for that entity. For example, a row in a users table would represent one individual user’s data (name, email, etc.).
- Column (Field): A column represents a specific attribute of the entity being modeled. Each column contains data of a particular type, like VARCHAR for text or INT for numbers.

Test automation example: As an SDET, you may be testing an e-commerce system. You need to verify whether product data is correctly inserted into the products table. Below’s an example of a table. Each row represents a product (Laptop, Headphones), and columns represent specific attributes of each product (e.g. product_id, product_name, price). To check if the Laptop product exists after an API or UI test, you might run:

SELECT * FROM products WHERE product_id = 1;

Table products:

Manual Tester Example: As a manual tester, after performing a transaction, you should confirm if a user record was correctly inserted. The users table may look like below. You could run the SQL to validate the presence of one user with the username given in the SQL query:

SELECT * FROM users WHERE username = 'john_doe';

Table users:

Question: What are common SQL data types, and why are they important?
Answer: SQL data types define the kind of data that can be stored in a column. Choosing the correct data type ensures data integrity, optimizes storage, and improves query performance.

SQL Data Type	Description	Example
VARCHAR(size)	Variable-length character string. It is used to store text data.	VARCHAR(50) can store text up to 50 characters long.
INT	Integer number. It is used to store whole numbers (e.g. age, quantity).	INT can store numbers like 42 or 1000.
DATE	Used to store calendar dates (year, month, and day).	DATE stores values like 2025-06-30.
DECIMAL(precision, scale)	Stores decimal numbers with exact precision, useful for monetary values.	DECIMAL(10, 2) stores values like 12345.67.

Example: If you are verifying if the correct data type is used in a table (e.g. price in a products table should be in decimals), you might check the schema (meaning table structure) with the following SQL. There is more in database schema testing, which I’ve explained in the database testing tutorial in my Software and Testing Training channel.

DESCRIBE products;

Question: What are DDL (Data Definition Language) commands, and how are they used?
Answer: DDL (Data Definition Language) commands are used to define, modify, and remove database structures such as tables, schemas, and indexes. These commands do not manipulate the data inside the tables but instead manipulate the schema.
- CREATE: Used to create a new database object (e.g. table, index).

- ALTER: Used to modify an existing database object (e.g. adding a column to a table). Example: 

ALTER TABLE employees ADD COLUMN salary DECIMAL(10, 2);

- DROP: Used to delete a database object. Example:

DROP TABLE employees;

Examples:

SDET Example: As an SDET, you may need to verify that a new table is created or modified correctly during automated tests. You might validate this with SQL commands such as CREATE and ALTER within your automation suite:

Manual Tester Example: While manual testers typically don’t create or alter database structures, you may need to confirm that a new table or column exists after a database migration. You might run the following SQL to check that a column like salary has been successfully added:

DESCRIBE employees;

Question: What are DML (Data Manipulation Language) commands, and how are they used?
Answer: DML (Data Manipulation Language) commands are used to manipulate the data within tables. These commands allow testers to retrieve, insert, update, and delete data in the database.

DML Command	Description	Example
SELECT	Retrieves data from one or more tables.	SELECT first_name, last_name FROM employees WHERE hire_date > '2025-01-01';
INSERT	Adds new records into a table.	INSERT INTO employees (employee_id, first_name, last_name, hire_date) VALUES (101, 'Inder', 'P Singh', '2025-01-01');
UPDATE	Modifies existing record in a table.	UPDATE employees SET salary = 50000 WHERE employee_id = 101;
DELETE	Removes record from a table.	DELETE FROM employees WHERE employee_id = 101;

Examples

SDET Example: In automated tests, you might run INSERT, UPDATE, and DELETE commands to verify how the system handles various data manipulations. For example, after adding a record to the employees table, you can check that it was inserted:

Manual Tester Example: As a manual tester, you may run SELECT queries to validate that updates or deletions performed through the application UI are reflected correctly in the database. For example:

SELECT * FROM employees WHERE first_name = 'Inder'; 

In order to dive deeper, you might view my tutorials on DBMS, database schema, relational algebra and relational calculus in my Software and Testing Training channel.

Question: How do you SELECT data from a single table?
Answer: I’ve demonstrated many SQL queries in my SQL queries tutorial at https://youtu.be/BxMmC77fJ9Y but, put simply, the SELECT statement is used to query data from a single table in a database. It allows testers to retrieve specific columns or all columns from the table.
1st technique: Retrieve specific columns from the table:

SELECT column1, column2, ... FROM table_name;

2nd technique: If you want to retrieve all columns, use \* instead:

SELECT * FROM table_name;

Test Automation Example: Suppose you're testing an e-commerce system, and you want to validate that the products table contains a specific product. You could run the following query into your test automation script to verify the presence and values of specific products:

SELECT product_id, product_name, price FROM products;

Manual Testing Example: If you want to manually check all customer details in a customers table, you can run the following query. will display all columns (like customer_id, customer_name, email, etc.) for all customers in the table, which you can visually inspect to verify.

SELECT * FROM customers;

Question: How do you filter data with WHERE clauses?
Answer: The WHERE clause is used to filter records based on specific conditions. WHERE clause is given after FROM table name. It narrows down the results to only those rows that meet the defined criteria. Its syntax is:

SELECT column1, column2, ... FROM table_name WHERE condition;

Test automation example: If you need to verify that products with a price above $100 exist in the products table, run the following query. You can use assertions in your automation code to validate the returned data matches your expectations.

SELECT product_id, product_name, price FROM products WHERE price > 100;

Manual Testing Example: If you want to manually check which customers registered after January 1st, 2025, you can run the following query. It will display only customers who registered after the specified date, allowing you to verify the filtering logic manually.

SELECT customer_id, customer_name, registration_date FROM customers WHERE registration_date > '2025-01-01';

Question: How do you sort data using ORDER BY?
Answer: The ORDER BY clause is used to sort the result set based on one or more columns. By default, it sorts in ascending order (ASC), but you can specify descending order (DESC) instead. The syntax is:

SELECT column1, column2, ... FROM table_name ORDER BY column_name [ASC|DESC];

Test Automation Example: If you want to validate that the products are listed in descending order by price in the products table, you can run the query below. The automation code can verify that the prices appear in the correct order as expected.

SELECT product_id, product_name, price FROM products ORDER BY price DESC;

Manual Testing Example: If you want to manually view a list of customers sorted by their registration date, run the query below. This will list all customers in increasing chronological (time) order, making it easier for you to validate registration trends.

SELECT customer_id, customer_name, registration_date FROM customers ORDER BY registration_date ASC;

Question: How can you limit results using SQL?
Answer: LIMIT (used in MySQL and PostgreSQL) or TOP (used in SQL Server) restricts the number of rows returned by a query, which is useful for testing with a subset of data.
 

Syntax (for MySQL/PostgreSQL):

 

Syntax (for SQL Server):

 

Test Automation Example: If you need to validate that only the top 3 most expensive products are returned, use the following query. This query can let you test pagination or validate specific subsets of data in the application.

SELECT product_id, product_name, price FROM products ORDER BY price DESC LIMIT 3;

Output:

Manual Testing Example: To manually check only the first 5 customers in the customers table, use the following query. This will show the top 5 rows in the table, allowing for quick data inspection during manual validation.

SELECT * FROM customers LIMIT 5;

If the system uses SQL Server, the equivalent query would be:

SELECT TOP 5 * FROM customers;

If you are finding my SQL post useful, you can follow me in in this Software Testing Space blog for more practical information in test automation and software testing by clicking the Follow button in the right pane.

Question: What are table relationships in SQL, and what are Primary Key and Foreign Key?
Answer: In relational databases, table relationships link data across different tables. The Primary Key and Foreign Key maintain these relationships:
* Primary Key (PK): A column (or a set of columns) that uniquely identifies each row in a table. It ensures that there are no duplicate or NULL values in that column.
* Foreign Key (FK): A column (or a set of columns) in one table that references the Primary Key of another table. It creates a link between two tables.
These keys allow us to join tables and combine data from multiple tables, ensuring data integrity.

Test automation example: You may have a customers table and an orders table. The customer_id column in customers table would be the Primary Key, and the customer_id column in orders table would be the Foreign Key. You can join these tables to check if each order is associated with a valid customer.
Manual Testing Example: A common database test (view my data testing tutorial) is validating data integrity between tables. For example, when manually testing a students table and a courses table, the student_id in the courses table should correspond to a valid student_id in the students table.

Question: What are the different types of joins in SQL?
Answer: Joins allow you to retrieve data from multiple tables based on related columns. I’ve explained and demonstrated joins (inner joins, left joins and self joins) in my SQL tutorial for beginners at https://www.youtube.com/watch?v=BxMmC77fJ9Y&t=518s

The most commonly used joins are:
- INNER JOIN: Returns only the rows that have matching values in both tables.
- LEFT JOIN (LEFT OUTER JOIN): Returns all rows from the left table and the matching rows from the right table. If no match is found, NULL values are returned from the right table.
- RIGHT JOIN (RIGHT OUTER JOIN): Returns all rows from the right table and the matching rows from the left table. If no match is found, NULL values are returned from the left table.
- FULL JOIN (FULL OUTER JOIN): Returns all rows from both tables, with NULLs where a match doesn’t exist in either table.

Question: How do you write SQL queries that combine data from multiple tables using joins?
Answer: You can write SQL queries that join two or more tables by specifying the relationship between the tables using the join condition (ON). Here are examples of how different joins work. 

 

Test automation example:
- INNER JOIN: Suppose you want to automate the validation of customer orders. You can write a query to ensure that every order has an associated customer. The query below retrieves only the orders that are linked to valid customers.

- LEFT JOIN: If you're testing for customers who haven’t placed any orders yet, you would use a LEFT JOIN to include all customers, even those without orders. The query below retrieves all customers, displaying NULL for orders for customers who haven't made any orders.

 

Manual testing example:
- RIGHT JOIN: If you're testing a healthcare system and want to verify that every patient has a doctor assigned, you would use a RIGHT JOIN to ensure that no patients are missing doctor assignments. The query below returns all patients, including those who may not yet have an assigned doctor.

- FULL JOIN: To manually check for any missing relationships between two tables in a database, you would use a FULL JOIN to get all rows from both tables, including rows with no match in either table. This allows you to detect any missing relationships.
Note: FULL JOIN / FULL OUTER JOIN exists in SQL Server, PostgreSQL, Oracle, etc. In MySQL, you must emulate it via LEFT JOIN UNION RIGHT JOIN or LEFT JOIN UNION ALL (without duplicates).

Question: What are some common test scenarios that need SQL joins?
Answer: Joins are used to validate data consistency and integrity between related tables.
Test automation example:
- Order validation: In e-commerce applications, SDETs can use INNER JOIN queries to validate that every order in the orders table has a valid customer in the customers table.
- Null data validation: Use LEFT JOIN to ensure no orphaned records exist, such as customers without associated orders or transactions. 

 

Manual testing example:
- Data consistency checks: When manually testing a student enrollment system, the tester can use a LEFT JOIN to check that all students in the students table are enrolled in at least one course, or use FULL JOIN to check for students or courses that don't match:

Note: For SQL training or DBMS training you can contact Inder P Singh on LinkedIn.

Question: How can you group data using GROUP BY and filter groups with HAVING?
Answer: GROUP BY is used to group rows that have the same values into summary rows, such as totals or counts. It is often combined with aggregate functions like COUNT, SUM, AVG, MIN and MAX. The HAVING clause is used to filter records after grouping has been applied, typically based on aggregate results. I’ve demonstrated GROUP BY and HAVING in my Software and Testing Training channel’s SQL tutorial from this time stamp in that video. 

 

Test automation example: You want to test that customer orders are grouped correctly by customer in an e-commerce system. The following query groups the orders by customer_id and calculates the total order value for each customer. It then filters groups to show only customers with a total order value above $500:

Manual testing example: In a sales application, you might manually test by checking which sales agents have completed more than 10 orders. You might use the GROUP BY and HAVING clauses as follows:

Question: What are aggregate functions, and how do you use them in SQL?
Answer: Aggregate functions perform calculations on multiple rows of data and return a single value. Common aggregate functions include:
- COUNT: Returns the number of rows.
- SUM: Adds up numeric values.
- AVG: Calculates the average value.
- MIN: Returns the smallest value.
- MAX: Returns the largest value.

Example: You want to test the total number of orders for each product. You can use the COUNT function to retrieve the total orders for each product_id:

Example: When testing a library system, you might need to manually check which book has the highest number of borrowings. Using MAX for this shows the book with the highest borrow count.

SELECT book_title, MAX(borrow_count) AS most_borrowed FROM books;

Question: How and when should you use subqueries (nested queries) in SQL?
Answer: You can learn about subqueries from my SQL tutorial for beginners from this timestamp. Basically, subqueries are queries inside another query. They are useful when you need to perform a query that relies on the result of another query.
- In the SELECT clause: To calculate derived columns.
- In the WHERE clause: To filter records based on another query's result.
- In the FROM clause: To create a temporary table for further querying.
 

Test automation example: You want to test whether orders with high totals have the highest-paying customers. You could use a subquery in the WHERE clause to find customers whose total order value exceeds the average:

SELECT customer_name
FROM customers
WHERE customer_id IN (
  SELECT customer_id
  FROM orders
  GROUP BY customer_id
  HAVING SUM(order_total) > (
    SELECT AVG(order_total) FROM orders
  )
);

Manual testing example: When testing an inventory system, you want to manually check the products with below-average stock levels. You might use a subquery in the WHERE clause:

Question: How can you combine query results using UNION and INTERSECT?
Answer: I’ve explained UNION etc. with examples in my SQL tutorial from this timestamp.
- UNION: Combines the results of two queries and removes duplicates.
- UNION ALL: Combines the results of two queries without removing duplicates.
- INTERSECT: Returns only the rows that are common to both queries.

Example 1: Suppose you're testing customer data stored in two different tables: active_customers and inactive_customers. You want to generate a list of all unique customers across both tables. Use UNION so that all unique customer records are retrieved from both tables:

Example 2: You’re manually testing an educational platform where you need to find students who are enrolled in both Math and Science courses. You can use INTERSECT to validate the students enrolled in both subjects:

More resources: If you want to see more examples, you can view them in my Database Testing tutorials . You can subscribe to my Software and Testing Training channel to get updates on new tutorials for SDET, QA and manual testers here.

Question: What are Common Table Expressions (CTEs), and how do you use them in complex queries?
Answer: A Common Table Expression (CTE) is a temporary result set defined within the execution of a SELECT, INSERT, UPDATE, or DELETE query. CTEs make complex queries more readable by allowing you to define and reuse subqueries. 

Test automation example: You want to test an e-commerce system to identify high-value customers, those who have placed orders totaling more than $1000. You can use a CTE to simplify the query as follows. It makes it easy to break the logic into manageable steps for your automation test.

Manual testing example: If you need to manually check the products with sales greater than $5000, you can use a CTE as follows to first aggregate sales data and then select only high-selling products. It helps in verifying large datasets step-by-step.

In fact, the manual tester can specialize in data quality. In my Data Quality tutorial below, I’ve explained the data quality concepts and data quality analyst role with many examples. Data Quality Concepts for Testers: https://youtu.be/N9olq42z-AE

Question: How do Window Functions like ROW_NUMBER(), RANK(), LEAD(), and LAG() work?
Answer: Window functions perform calculations across a set of table rows related to the current row. They do not collapse rows into groups like aggregate functions but allow the result of a function to be "windowed" over rows.
- ROW_NUMBER(): Assigns a unique sequential integer to rows.
- RANK(): Similar to ROW_NUMBER(), but assigns the same rank to rows with equal values.
- LEAD(): Returns the value of the next row.
- LAG(): Returns the value of the previous row.
 

Test automation example: You want to test that customer orders are ranked by total order value. You can use RANK() as follows to identify the top three customers by order amount. It validates that your application correctly ranks top customers.

Manual testing example: To check the order history and identify sequential patterns, you might use LAG() to compare current and previous order dates for each customer. It helps in manually reviewing customer behavior and order trends.

SELECT customer_id, order_date,  
LAG(order_date, 1) OVER (PARTITION BY customer_id ORDER BY 
order_date) AS previous_order 
FROM orders;

Question: How do you create and use VIEWS for testing purposes?
Answer: I’ve explained how to test database schema objects like TABLE, VIEW, STORED PROCEDURE AND TRIGGERS in my Database Testing tutorial from this time stamp. But, as far as a VIEW is concerned, it’s a virtual table that consists of a SQL query result. It simplifies complex queries by allowing you to encapsulate them within a reusable object.
 

Test automation example: You need to repeatedly test data on active customer orders. Instead of writing complex queries in each automated test, you can create a VIEW for active orders:

You can test this view with a simple SQL query:

SELECT * FROM active_orders;

Manual testing example: In an inventory system, to test low-stock products regularly, create a VIEW like below:

You can now manually check low stock levels using: 

Question: How do you use indexes and optimize queries for large datasets?
Answer: Indexes improve the speed of data retrieval by creating a data structure (index) that allows the DBMS to find rows more quickly. However, they can slow down INSERT, UPDATE, and DELETE operations. 

Test automation example: When testing an application that retrieves customer records, performance may degrade as the dataset grows. You can optimize a query using an index on the customer_id column:

Now your following SQL query will run faster, especially with large datasets:

SELECT * FROM customers WHERE customer_id = 123;

Manual testing example: If manually retrieving product data is slow, you can save your time by adding an index on the product_name column. It should improve query speed when searching for product names.

Question: How do you handle SQL transactions with COMMIT, ROLLBACK, and SAVEPOINT?
Answer: A transaction is a sequence of operations performed as a single logical unit of work. Transactions ensure that either all operations succeed or none at all (atomicity).
- COMMIT: Saves all changes made in the transaction.
- ROLLBACK: Reverts the changes made in the transaction.
- SAVEPOINT: Sets a point within a transaction to which you can roll back partially. 

Test automation example: You're testing a banking application where funds are transferred between accounts. You use a transaction to ensure that both debit and credit actions occur together:

If there's an issue during the transfer, you can roll back using the following SQL query:

ROLLBACK;

Manual testing example: When testing an inventory system, you may use transactions to ensure that updating stock quantities is atomic. This helps to maintain your test environment’s data integrity by ensuring that the stock update is not partially completed:

Want to learn more? You can message me on LinkedIn to get my complete SQL document that includes SQL in Different Database Platforms (Oracle, PostgreSQL, SQL Server and NoSQL Databases (MongoDB)), SQL Queries for Manual Testers, SQL in Automation Testing (Java, Python, etc.) and SQL for API Testing, SQL Queries for Performance Testing, Data Validation Using SQL, More SQL Questions for QA Interview Preparation and Writing SQL queries for real-world problem-solving in interviews, Scenario-based SQL questions, Best practices for SQL-based problem-solving in QA interviews, SQL Best Practices for Testers and Best practices for organizing SQL queries in testing projects and SQL Tips and Tricks for QA Testers. Thank you!