JMeter Interview Questions and Answers on JMeter Load Testing

Here are my JMeter Interview Questions and Answers on JMeter Load Testing for Performance Testers, SDET, and QA Testers. Read the interview questions on JMeter for Load Testing, JMeter Download and Installation, JMeter Concepts (Thread Groups, Samplers, Listeners, Controllers) and JMeter test plans, JMeter Load Testing Concepts (Assertions and Timers in JMeter, Load testing APIs, Correlation and Parameterization), Advanced JMeter Features (such as Distributed load testing with JMeter, Using Regular Expression Extractor and JMeter plugins) and Analyzing JMeter Test Results.

If you want my complete set of JMeter 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:
Performance Tuning with JMeter (running in non-GUI mode, managing resources and JMeter for large-scale performance testing), JMeter Interview Questions for QA, SDETs, and Testers on fundamental, intermediate, and advanced concepts, including Scenario-based JMeter interview questions and JMeter Tips, Tricks, and Best Practices (for efficient and maintainable JMeter test and integrating JMeter with CI/CD pipelines).

Question: What is JMeter, and why is it useful for load testing?
Answer: Apache JMeter is an open-source tool used for load testing, performance testing, and limited functional testing of web applications and other services. JMeter simulates multiple users or requests to test how an application performs under load and stress conditions. You can get an introduction to JMeter by viewing my Load Testing in JMeter and JMeter testing short tutorials. JMeter is useful for load testing for several reasons:
- Scalability testing: JMeter can test the application's ability to handle heavy requests traffic and user load.
- Server performance evaluation: It can measure response times, and throughput under various loads.
- Free: As an open-source tool, JMeter is freely available and eliminates the license costs of commercial testing tools.
Cross-platform compatibility: It supports a wide range of protocols like HTTP, FTP, SOAP, JDBC, making it suitable for testing different types of systems.
- Ease of use: Its GUI-based approach makes it easy for QA engineers and SDETs to design and run complex test plans with minimal scripting knowledge. You can view a basic JMeter load test in my JMeter load testing tutorial below.

Example: Suppose you’re are tasked with performance testing an e-commerce website that expects 10,000 concurrent users on Black Friday. JMeter can simulate that load and measure how the website performs under stress, helping identify bottlenecks like slow database queries or inadequate server capacity.

Question: What are the key features of JMeter for SDETs and QA engineers?
Answer: JMeter has many features that are useful for SDETs and QA engineers:
- Thread Groups: These define the number of users (threads), ramp-up time, and loop count for the test. You can simulate a realistic load by configuring multiple users and testing how the application behaves when users hit the server concurrently (simultaneously). Example: Simulating 100 virtual users accessing a web app over 5 minutes. 
- Samplers: They define the types of requests (e.g., HTTP, FTP, JDBC) that JMeter sends during testing. Samplers allow you to test various protocols, from web pages to databases, without switching tools. Example: Sending HTTP POST requests to test API endpoints, retrieving data from a MySQL database via JDBC Sampler. 
- Listeners: They collect and visualize results such as response times, throughput, and error rates. Listeners provide real-time feedback during test runs, helping testers diagnose issues quickly. Example: Using the "View Results Tree" or "Aggregate Report" listener to analyze failed requests and spot slow responses. 
- Assertions: They validate whether a server's response meets certain conditions (e.g., response contains specific text, response time is within a limit). 
- Assertions test the functionality under load, making sure that results match the expected behavior. Example: QA engineers can set up an assertion to check if a login response contains the text "Welcome back" to confirm successful logins. 
- Correlation & Parameterization: They extract and reuse dynamic data (e.g., session IDs) from responses and input them into subsequent requests. They are needed for testing realistic workflows like logging in, searching, and placing orders, where dynamic data changes between actions. Example: Extracting a session token from an authentication response and using it in a subsequent request to fetch user details. 
- Timers: They control the time delay between requests. Timers simulates real user interactions more accurately instead of sending requests in rapid succession. Example: Adding a 2-second delay between requests to simulate the time users take to browse before moving to the next page. 
- Extensibility with Plugins: The plugins add extra functionality like advanced graphing, custom thread groups, or server monitoring. You can enhance JMeter's capabilities by using plugins such as PerfMon to monitor CPU, memory, and disk usage on the server. Example: Installing the Throughput Shaping Timer plugin to manage custom traffic patterns like sudden load spikes. 
- Non-GUI mode for large-scale testing: You can run JMeter in non-GUI (command-line) mode to handle high loads without straining your machine's resources. Performance testers and SDETs can execute extensive load tests on cloud servers or CI/CD pipelines without JMeter's graphical overhead. Example: Running a JMeter test plan with 10,000 virtual users on AWS instances to test a production environment's readiness. 
- JMeter Distributed Testing: It splits tests across multiple machines to simulate large scale user loads. It’s useful for enterprise-level performance testing where thousands of users need to be simulated. Example: Using multiple JMeter servers to simulate 50,000 concurrent users hitting a banking app.
Tip 1: If you’re new to JMeter, you can view JMeter features in my JMeter performance testing tutorial from the time-stamp.

Tip 2: Always monitor your system's resource usage when running load tests to ensure JMeter itself isn't becoming a bottleneck. Use tools like JVisualVM to monitor CPU and memory consumption.

Question: How can you download JMeter for Windows, Mac, and Linux?
Answer: JMeter is platform-independent, so downloading and installing it on Windows, Mac, or Linux follows a similar process:
- Go to the Apache JMeter official website: Visit JMeter Download Page to get the latest version.
- Download the binary: Look for the Binaries section, and download the zip file for your OS. There’s no installer for JMeter, just a zipped package. For Windows, download the .zip file. For Mac/Linux, download the .tgz file.
- Extract the archive: Windows: Right-click on the downloaded .zip file and select Extract All. Mac/Linux: Open the terminal, navigate to the file's directory, and use tar -xvzf <filename>.tgz
- Verify Java is installed: JMeter needs Java 8 or above to run. You can verify if Java is installed by running the following command in the command prompt window or terminal:

java -version

If Java isn’t installed, you can download it from Oracle's website.
- Run JMeter: Navigate to the JMeter bin folder (where you extracted the files). For Windows, double-click jmeter.bat. For Mac/Linux, run ./jmeter from the terminal.
Tip: It's good practice to update JMeter to the latest stable version before starting new projects so that you have the latest features and fixes.

Question: How do you set up JMeter and what’s its file structure?
Answer: After downloading and extracting JMeter, you'll see several folders and files. The key directories and files are: 
- /bin: Contains executable files like jmeter.bat (for Windows) or jmeter (for Mac/Linux). You will run JMeter from here. 
- /docs: Contains JMeter documentation, which provides detailed information on usage. 
- /extras: Includes additional tools like JMeter plugins and Ant tasks. 
- /lib: Contains the necessary libraries JMeter uses to run different samplers and components. 
- /lib/ext: This is where you’ll install any additional plugins. 
- /lib/junit: JUnit testing libraries are stored here. 
- /logs: Stores logs that JMeter generates during the test execution. 
- /printable_docs: Contains documentation in a printable format. 
- /licenses: Stores the license information of JMeter and its dependencies. 
JMeter Test Plan File (.jmx): The test plan you create in JMeter is saved as a .jmx file (XML format). This file contains your entire test plan configuration, including thread groups, samplers, listeners, and assertions. Keep your test plans and related data files (e.g., CSV for data-driven testing) in separate directories for large-scale projects. This practice improves maintainability and collaboration in teams.

Question: How can you install and use the JMeter Plugin Manager?
Answer: JMeter Plugin Manager is the tool that allows you to install and manage various JMeter plugins to extend its functionality. Here’s how you can install and use it: 
- Installing the Plugin Manager: Go to the JMeter Plugins website. Download the Plugins Manager JAR file (JMeterPlugins-Manager-x.x.jar). Copy the JAR file into the /lib/ext directory inside your JMeter installation folder. Restart JMeter, and you’ll now see Plugins Manager under the Options menu. 
- Using the Plugin Manager: Open JMeter, and go to Options > Plugins Manager. In the Available Plugins tab, you'll see a list of plugins that you can install. Popular plugins include: - PerfMon (Servers Performance Monitoring): Monitors server health (CPU, memory, disk usage) during tests. - Throughput Shaping Timer: Controls the throughput of requests to simulate traffic spikes. - Custom Thread Groups: Offers more advanced thread group configurations like Stepping Thread Group and Concurrency Thread Group. Select the plugins you need, click Apply Changes and Restart JMeter.
Example: Let’s say you want to monitor the CPU and memory usage on your server while running a test. By installing the PerfMon plugin, you can connect it to the server and collect resource usage data during load testing, helping you identify bottlenecks.
Tip: Always check for plugin updates in the Plugin Manager to make sure you’re using the latest versions, as newer versions often provide performance improvements and bug fixes.
Example: View my Performance Testing Interview Questions and Answers video.

Question: What are the JMeter test elements such as Thread Groups, Samplers, Listeners, and Controllers?
Answer: JMeter’s architecture has several core elements. Each plays a specific role in load testing:
- Thread Groups: Thread Groups represent virtual users. They define how many users (threads) will be simulated, how they ramp up, and how long they will stay active. For example, if you set the number of threads to 50, JMeter will simulate 50 users hitting your application.
- Samplers: Samplers are the actual requests being sent to the server. They simulate actions a user might perform, such as visiting a webpage or submitting a form. Examples include HTTP Sampler (for web requests) and JDBC Sampler (for database queries). Tip: For a web application, use HTTP Samplers to simulate GET/POST requests to your server and analyze the response times.
- Listeners: Listeners collect the results of your load tests and present them in various formats like tables, graphs, or logs. Popular listeners include View Results Tree (for detailed request-response logs) and Aggregate Report (for summarizing results such as response time and throughput).
- Controllers: Controllers allow you to define the logic of your test. There are two types of controllers: 
o Logic Controllers: These control the flow of the requests. For example, you can use a Loop Controller to repeat a request multiple times or an If Controller to define conditional execution.
o Transaction Controllers: Used to group multiple requests as a single transaction for better analysis.
Example: If you're testing a login page, you could set up a Thread Group with 100 users, an HTTP Request Sampler to submit the login form, and a Listener to record the response times.

Question: What is a JMeter test plan, and how can you configure ramp-up periods and thread properties?
Answer: A Test Plan in JMeter is like a blueprint that contains all the test elements (Thread Groups, Samplers, Controllers, etc.). It represents the configuration of your performance test.
- Thread Properties: 
a. Number of Threads (Users): This is the number of virtual users that will be simulated. For example, setting this to 200 will simulate 200 users concurrently accessing your application.
b. Ramp-up Period: The time (in seconds) that JMeter will take to start all users. For example, a ramp-up period of 100 seconds with 50 users means JMeter will start one new user every 2 seconds (100/50).
c. Loop Count: Defines how many times the test will be executed. If set to forever, the test will keep running until manually stopped.
Tip: It’s best to use a gradual ramp-up period to avoid overwhelming the server with all users at once. For example, in real-world scenarios, users don’t log in all at the same time. 
Ramp-Up Example: Suppose that you have a test with 500 users and a ramp-up period of 100 seconds. If the ramp-up period is too short (say 10 seconds), all 500 users will hit your application almost immediately (within 10 seconds), potentially causing an unrealistic load. By increasing the ramp-up to 100 seconds, users are introduced more gradually, simulating real traffic better.

Question: How can you run a basic JMeter load test for web applications?
Answer: I’ve demonstrated a basic JMeter load test on this blog, Software Testing Space in my short JMeter tutorial. Running a basic load test in JMeter involves several steps:
- Create a Thread Group: Go to Test Plan > Add > Threads (Users) > Thread Group. Set the number of users, ramp-up period, and loop count based on your requirements.
- Add HTTP Sampler: Right-click on the Thread Group and go to Add > Sampler > HTTP Request. Configure the following: 
a. Server Name or IP: Enter the domain name (e.g., www.example.com).
b. Method: Choose between GET or POST depending on the request.
c. Path: The URL path, such as /login for login requests.
- Add a Listener: Add a listener to monitor the test. Right-click the Test Plan and go to Add > Listener > View Results Tree or Aggregate Report. These show the test’s performance metrics. Tip: Since any listener takes up resources, add only the minimum number of listeners.
- Execute the Test: Click on the Start button (green play icon). As JMeter runs, you can see real-time test results in the listener you added. Look for metrics such as response time, throughput, and error percentage.
- Analyze Results: After the test is complete, analyze the data from the listner that you added e.g., Aggregate Report. Key metrics to focus on include: 
a. Average Response Time: How long, on average, your application takes to respond to requests.
b. Throughput: The number of requests your server can handle per second.
c. Error Rate: The percentage of failed requests.
Example: If you run a test with 100 users hitting a login page every 5 seconds, you can check whether the response times are acceptable under load or whether any errors occur (e.g., HTTP 500 or 504).
Tip: Always run several small-scale tests first before scaling up to higher loads. This will enable you to identify potential test plan issues early on and fine-tune the test plan.

Question: How can you use Assertions and Timers in JMeter to improve testing accuracy?
Answer: Assertions and Timers help in making the load tests accurate and realistic.
- Assertions: Assertions validate that the server’s response meets expected conditions, which validates that your application behaves correctly under load. Commonly used assertions include: 
o Response Assertion: Validates that the server’s response contains a specific string or meets a pattern. For example, you can check if the login page returns a 200 OK status or if the page contains the word "Success." 
o Duration Assertion: Ensures the response time does not exceed a certain threshold, e.g., a page must load within 2 seconds.
Example: In a login test, you can use a Response Assertion to ensure the login page returns the message "Login Successful" after the user submits valid credentials.
- Timers: Timers are the delays between requests. Without timers, JMeter sends requests as fast as possible, which is unrealistic user action. Common timers include: 
o Constant Timer: Adds a fixed delay between requests, e.g., 2 seconds. 
o Gaussian Random Timer: Adds a variable delay with a normal distribution, e.g., an average delay of 5 seconds with a deviation of 1 second.
Tip: Use a Constant Throughput Timer to control the pace of requests, so that the server receives a steady number of requests per second.

Question: How can you load test APIs using JMeter HTTP Samplers?
Answer: API load testing can be done using JMeter. The HTTP Sampler is used to simulate API requests (GET, POST, PUT, DELETE) and test the performance of RESTful or SOAP APIs under load.
- Add an HTTP Sampler: Create a new Thread Group in your test plan. Then, add an HTTP Request Sampler by right-clicking the Thread Group and selecting Test Plan > Add > Sampler > HTTP Request.
- Configure the API request: In the HTTP Sampler, configure the following fields: 
o Server Name: Enter the API endpoint, e.g., api.example.com.
o Method: Choose the appropriate HTTP method (e.g., GET or POST).
o Path: Specify the API path, such as /api/v1/users.
o Parameters: For POST/PUT requests, you can add parameters or a request body (e.g., JSON data).
- Add Assertions: Add a Response Assertion to verify the API response. For example, you can check if the response contains a success code like 200 OK or a specific JSON key.
- Analyze the results: Run the test and monitor the results using Listeners like View Results Tree or Aggregate Report. Key metrics to check include response time, throughput, and error rate.
Example: When testing a user login API, configure the HTTP Sampler to POST user credentials, add a JSON body, and validate that the API returns a JWT token or "Login Successful" message.
Tip: When testing APIs with authentication (e.g., token-based), you can handle dynamic tokens and session values through correlation techniques, which we’ll cover next.

Question: What is correlation and how does parameterization with CSV Data Set Config work in JMeter?
Answer: Correlation is the process of handling dynamic values that the server generates during a session (e.g., session IDs, tokens). In load testing, you need to capture these dynamic values from one request and use them in subsequent requests.
- Parameterization allows you to send varied input data, improving test realism by simulating different users.
Correlation Example: Suppose you’re testing a login page that returns a session ID. You can extract this session ID from the response using a Regular Expression Extractor or JSON Extractor. Once extracted, you can store this value in a variable and reuse it in subsequent requests (e.g., making authenticated API calls with the session ID).
Parameterization with CSV Data Set Config: The CSV Data Set Config allows you to read input data (such as usernames and passwords) from an external CSV file. This is useful for testing multiple scenarios with different data inputs, making your load test more realistic.
Steps to Parameterize:
- Create a CSV file (e.g., users.csv) with multiple rows of data (e.g., usernames, passwords).
- Add a CSV Data Set Config to your test plan and specify the file path.
- Assign column values to variables (e.g., ${username} and ${password}), which can then be used in HTTP requests.
Example: If you are load testing a registration page, you can use CSV parameterization to input different usernames and passwords, such that each request registers a new user. This avoids response caching by the server, resulting in a realistic load test.
- Tip: Always ensure your CSV file has sufficient data to handle the number of threads in your test. For instance, if you’re running a test with 100 users, make sure your CSV file has at least 100 rows of unique usernames and passwords combinations.

If you’re finding these JMeter questions and answers useful, please follow me by clicking the Follow button (in the right pane) to get more practical test automation and software testing resources.

Question: How can you perform distributed load testing with JMeter?
Answer: Distributed load testing in JMeter allows you to simulate a larger number of users by distributing the request load across multiple machines (called load generators). This is useful when you need to simulate heavy request traffic that exceeds the capacity of a single machine.
- Set up the Master and Slave machines 
o Master Machine: Controls the test and aggregates the results from the slaves.
o Slave Machines: Execute the test plan by generating traffic.
- Configure 
o On each slave machine, navigate to the jmeter.properties file and set the server.rmi.ssl.disable=true property to allow communication. 
o On the master machine, modify the remote_hosts property in the jmeter.properties file by adding the IP addresses of the slave machines (e.g., 192.168.1.101,192.168.1.102).
- Run the Test 
o Start JMeter in server mode on each slave machine by running

jmeter-server

o On the master machine, run the test in distributed mode by using the command line:

jmeter -n -t testplan.jmx -r

The -r flag tells JMeter to execute the test across remote servers (the slaves).
- Monitor Results: Use Listeners on the master machine to monitor and collect results from all slave machines. 
Tip: All machines (master and slaves) should have the same version of JMeter and Java installed. Before setting up the distributed testing, test that they can communicate over the network without firewalls blocking communication.

Question: How can you handle dynamic data using Regular Expression Extractor in JMeter?
Answer: The Regular Expression Extractor in JMeter can handle dynamic data such as session IDs, tokens, or any changing values returned by the server. This process, known as correlation, extracts the dynamic values from one request and reuses them in subsequent requests.
- Add a Regular Expression Extractor 
o After the sampler that generates the dynamic value (e.g., a login request), right-click the sampler and select Add > Post Processor > Regular Expression Extractor.
- Configure the Regular Expression Extractor 
o Reference Name: This is the variable that will store the extracted value (e.g., sessionID).
o Regular Expression: Write a regex pattern to extract the desired value. For example, to extract a session ID from a response that looks like sessionID=abcd1234;, use the pattern sessionID=(.+?);.
o Template: Use $1$ to refer to the extracted group.
o Match No: Set this to 1 to extract the first match or -1 to extract all matches.
o Default Value: Set a default value to be used if the pattern is not found (optional).
- Use the extracted variable in subsequent requests
o In the next sampler (e.g., making an authenticated API call), refer to the extracted value using the syntax ${sessionID}.
Example: In a scenario where the server returns a session token after login, use a Regular Expression Extractor to capture the token and then include it in subsequent API calls for authenticated access. The regular expression might look like token=(.+?)" to extract a token value like token=abc123.
Tip: Test your regular expressions with tools like online tools before applying them in JMeter.

Question: What are some advanced JMeter plugins that you can use for extended functionality?
Answer: JMeter’s plugins provide additional functionality that extend JMeter’s default capabilities. Some key plugins include PerfMon and Custom Thread Groups, which are typically used for advanced performance testing.
- PerfMon (Performance Monitoring Plugin): PerfMon allows you to monitor server-side metrics (CPU, memory, network usage) during a load test, giving you data about how the server behaves under load. The steps to use it are: 
o Install the PerfMon Server Agent on the server you want to monitor.
o Add the PerfMon Metrics Collector listener in JMeter.
o Configure the IP address and port to match the server running the agent. You can then monitor metrics like CPU usage or memory consumption in real-time during the test.
Example: While running a load test on an API server, you can use PerfMon to monitor the server’s CPU utilization. If CPU usage reaches 90%, it might indicate a performance bottleneck (meaning a constraint) at higher loads.
- Custom Thread Groups: Custom Thread Groups allow you to define more sophisticated user behavior and traffic patterns than the default Thread Group. Two options are:
o Ultimate Thread Group: Lets you configure varying user load patterns, such as ramping up users gradually and then dropping them off over time.
o Stepping Thread Group: Allows you to increase the load in steps (e.g., add 10 users every 30 seconds) to test how the application scales under gradual pressure.
Example: Using the Stepping Thread Group, you can simulate a gradual increase in traffic for an e-commerce website, starting with 10 users and adding more every minute until you reach 100. This gives you clearer data about when performance degradation starts.

Question: What are JMeter Listeners, and how do they help in understanding performance metrics?
Answer: Listeners in JMeter collect and display test results. They provide insights into performance metrics like response time, throughput, and error rates. Some commonly used listeners include:
- View Results Tree: It displays request and response details in real-time for each sampler. It's useful for debugging by checking request headers, response bodies, and HTTP codes.
- Aggregate Report: Provides a consolidated summary of important performance metrics: 
o Label: The name of the sampler.
o # Samples: Total number of requests.
o Average: Average response time (ms).
o Min and Max: Minimum and maximum response times.
o Throughput: Number of requests processed per second or minute.
o Error %: Percentage of failed requests.
Example: During an API load test, if the Error % exceeds 2%, you might investigate into the responses using the View Results Tree to understand what's causing the errors (e.g., server timeouts or incorrect request data).
- Summary Report: It's Similar to the aggregate report but simpler. It shows key data like average response time, standard deviation, and throughput in a tabular format. 
Tip: It's okay to enable detailed listeners only for debugging and to use only aggregate reports during large load tests.

Question: How can you generate and interpret JMeter performance reports?
Answer: JMeter has reporting capabilities to generate detailed performance reports in HTML format. To generate a JMeter report:
- Run your test in non-GUI mode: Running tests in non-GUI mode gives better performance. Use the following command to generate a report:

-n: Non-GUI mode.
-t: Test plan file.
-l: Log file for storing the results.
-e: Generate an HTML report.
-o: Output folder for storing the report.
- Review the HTML report: The report contains several key metrics: 
o Response Time Over Time: A graph showing how response times fluctuate throughout the test.
o Transactions Per Second (TPS): Displays how many transactions are processed per second, which is a key metric to check the scalability of your application.
o Error Summary: Lists all the errors encountered during the test, helping identify critical issues.
o Latency: Time taken from sending a request to receiving the first response byte.
Example: After testing an e-commerce site, you notice that the Response Time Over Time graph shows a sharp increase after the first 500 users, indicating a potential performance bottleneck.
- Understanding Key Metrics: 
o Response Time: Measure of how quickly the server responds to requests. Lower is better.
o Throughput: Measures how many requests are processed per second/minute. Higher is better.
o Error Rate: Percentage of failed requests. A high error rate suggests server issues, bad requests, or failed authentications. Lower is better
Tip: Focus on Response Time and Throughput. They are often the most critical indicators of your application's performance under load.

Question: What are some best practices for analyzing and reporting load test results?
Answer: Effective analysis and reporting of JMeter results is needed for making informed decisions about your application's performance. Here are some best practices:
- Establish a Baseline: Before you start load testing, determine your baseline performance under minimal load conditions. This gives you data to compare the performance when load increases.
Example: If the baseline response time for your API is 500ms under 10 users, and it increases to 2000ms with 100 users, you can measure the impact of scaling on performance.
- Compare Actual Results to SLAs: Select your load test metrics according to the performance Service Level Agreements (SLAs). If your SLA requires a maximum response time of 2 seconds under 1000 users, any result that exceeds this threshold needs attention.
- Use Granular Results: Instead of focusing on average response times, analyze other statistical measures too: 
o a. Percentiles (90th/95th): Helps identify outliers that might skew the average. Example: If your test has an average response time of 1 second but a 90th percentile of 3 seconds, it means that while most users experience fast response times, the slowest 10% are facing unacceptable delays.
o b. Standard Deviation: Gives insight into how stable your performance is across requests. A high deviation means response times are inconsistent, which can lead to a poor user experience.
- Break Down Results by Transaction Type: Break down the results by specific transactions (e.g., login, search, checkout). Different parts of your application may have different performance characteristics, and bottlenecks might only show up in specific areas. Example: Your test shows that the checkout process is slow but the login process is fine. By isolating transactions, you can focus your performance engineering efforts on problematic areas.
- Visualize Data: Use JMeter’s Graphs and Charts to make your analysis easier to understand. Visual representation often highlights performance trends better than raw data. Ensure that your report includes graphs showing response times, throughput, and error rates over time.
- Document Your Findings: Summarize your results in a report, displaying key findings such as: 
a. Comparisons to previous test results or SLAs
b. Performance bottlenecks/ areas of improvement
c. Suggested optimizations for the application or infrastructure
Tip: Include detailed logs and graphs to support your findings. A report with actionable insights will help the developers and other stakeholders take the next steps. 

 

Want to learn more? If you want my complete set of JMeter Interview Questions and Answers as a document that additionally contain the following topics, you can message me on LinkedIn:
Performance Tuning with JMeter (running in non-GUI mode, managing resources and JMeter for large-scale performance testing), JMeter Interview Questions for QA, SDETs, and Testers on fundamental, intermediate, and advanced concepts, including Scenario-based JMeter interview questions and JMeter Tips, Tricks, and Best Practices (for efficient and maintainable JMeter test and integrating JMeter with CI/CD pipelines). 

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!