What Is System Testing? Types, Process and Real-World Examples
System testing checks whether a complete software application works as expected. It helps identify problems that may occur when different features work together. In this article, we'll explain system testing, its types, how it works, and practical examples to help you understand it better.
What Is System Testing in Software Testing?
System testing is a level of software testing in which the complete, integrated application is tested against its specified requirements. It checks whether the software functions correctly and meets expected quality standards.
Unlike unit testing, which focuses on individual components, system testing examines the application as a whole.
Consider an online shopping website. A customer can search for products, add items to a cart, make payments, and track orders. Each feature may work correctly when tested separately. However, problems can appear when customers use these features together.
Suppose a customer pays successfully and the order is confirmed, but the stock count never goes down. The next customer can then buy the same last item. The payment feature passes its tests, and so does the order feature. The problem only shows up when someone checks the complete purchase flow from start to finish.
System testing helps identify such problems by checking the complete shopping process. Some of these defects may also surface earlier during integration testing. System testing confirms that the whole flow works once everything is in place.
It commonly uses black-box testing techniques, where testers check application behaviour without examining its internal code. The objective is to verify that the integrated application meets its requirements and works correctly under different conditions.
Why Is System Testing Important?
A software application can pass unit testing and integration testing but still have problems when users interact with it. Different features often depend on one another, so even a small issue in one part can affect an entire workflow. System testing helps identify these issues before the software is released.
Here are some reasons why it is important:
Checks complete functionality: verifies that different features work together as expected.
Identifies hidden defects: finds problems that may have been missed during earlier testing.
Validates requirements: confirms that the application meets its specified functional and quality requirements.
Improves software reliability: helps identify failures that could affect users.
Reduces release risks: allows teams to investigate important issues before deployment.
Evaluates overall performance: checks how the application behaves under different operating conditions.
Imagine transferring money through a banking application. The sender's account shows that the transaction was successful, but the recipient has not received the money. Individual components may have passed earlier tests, yet the complete transaction has failed. System testing helps identify problems in such connected workflows.
When Is System Testing Performed?
System testing generally takes place after integration testing and before acceptance testing. At this stage, the relevant software components have been integrated into a working application.
Software testing is commonly divided into four levels:
Unit testing: tests individual functions, methods, or components.
Integration testing: checks interactions between connected components.
System testing: tests the complete application against its requirements.
Acceptance testing: determines whether the software meets agreed acceptance criteria.
These levels describe different testing objectives. In Agile projects, testing activities may overlap or repeat during development.
Who Performs System Testing?
System testing is usually performed by QA engineers or software testers. Depending on the project, developers, performance testers, security specialists, and other technical team members may also take part.
Entry criteria
Before system testing begins, the team should confirm that:
The required application features have been integrated.
The test environment is available.
Requirements are clear enough to create test cases.
Required test data is prepared.
Major integration issues have been resolved or assessed.
These conditions are called entry criteria. They help determine whether the application is ready for system testing.
Exit criteria
Exit criteria are the conditions that tell the team system testing can stop. Agree on them before testing starts, so the decision is based on evidence and not on deadline pressure. Typical exit criteria include:
All planned test cases have been executed.
No critical or high-severity defects remain open.
Regression tests have passed after the final fixes.
Important requirements are covered by test cases.
Remaining risks are documented and shared with stakeholders.
The exact thresholds differ between projects. What matters is that the team agrees on them in advance.
What Are the Types of System Testing?
System testing includes different testing activities that examine how the complete application behaves. These activities are broadly classified as functional and non-functional testing.
Functional system testing checks whether the application performs the actions described in its requirements. It verifies, for instance, whether a customer can successfully place an order on an e-commerce website.
Non-functional system testing evaluates quality characteristics such as performance, security, usability, and reliability. It checks, for instance, whether the same website stays responsive when many customers use it at the same time.
The following table explains common types of system testing.
Type of System Testing | Purpose | Example |
Functional Testing | Checks whether application features work according to requirements | Verifying that customers can complete online purchases |
Regression Testing | Confirms that new changes haven't broken existing features | Re-running checkout tests after a coupon bug is fixed |
Smoke Testing | Quickly checks whether a new build is stable enough for further testing | Confirming that login and the home page load after a new deployment |
Performance Testing | Evaluates application speed and responsiveness | Measuring the time taken to load a product page |
Load Testing | Checks application behaviour under expected user traffic | Testing a website with 1,000 simultaneous users |
Stress Testing | Evaluates behaviour beyond normal operating limits | Increasing traffic until the application reaches its capacity |
Security Testing | Identifies security weaknesses | Checking whether one customer can access another customer's information |
Usability Testing | Evaluates how easily users interact with the application | Checking whether customers can complete checkout without confusion |
Accessibility Testing | Checks whether people with disabilities can use the application | Navigating checkout with a screen reader and keyboard only |
Compatibility Testing | Checks behaviour across supported platforms | Testing a website in Chrome, Firefox, and Safari |
Recovery Testing | Checks whether the application can recover from failures | Verifying recovery after a database connection failure |
Reliability Testing | Evaluates consistent operation over time | Checking whether scheduled transactions continue to run correctly |
Not every application requires the same testing activities. Security and reliability are particularly important in banking applications, while compatibility may be a major concern for websites used across many browsers and devices. Testers select the relevant testing activities based on project requirements and risks.
How Is System Testing Performed?
System testing follows a planned process. Testers begin by understanding the requirements and then prepare, execute, and evaluate test cases. The exact workflow differs between projects, but the following steps explain how system testing is generally performed.
Step 1: Understand the Software Requirements
Before testing an application, testers must understand what it is supposed to do. Requirements explain the expected functionality, business rules, and quality expectations.
Take a food delivery application. One requirement states that customers should be able to select a restaurant, place an order, complete payment, and track the delivery. A tester needs to understand what should happen during each step.
They must also consider situations such as failed payments, unavailable restaurants, cancelled orders, and delivery status updates. Understanding these conditions helps testers identify meaningful test scenarios.
Step 2: Prepare a System Test Plan
Once the requirements are understood, the testing team prepares a test plan. The plan explains what needs to be tested, which resources are required, and how the testing activities will be managed.
A system test plan generally includes:
Features and workflows included in testing
Testing objectives and scope
Test environment requirements
Testing techniques and tools
Roles and responsibilities
Test schedule
Entry and exit criteria
Known risks and dependencies
If the team is testing a shopping application, the plan may prioritise checkout, payment processing, and order management, because problems in these workflows can directly affect customers. A clear plan helps testers organise their work and avoid missing important features.
Step 3: Identify Test Scenarios and Write Test Cases
After preparing the plan, testers identify situations that need to be checked. A test scenario describes what needs to be tested, while a test case explains how to test it.
Take the login feature of an application. A test scenario could be: Verify that a registered user can log in successfully. The corresponding test case would include these steps:
Open the application's login page.
Enter a registered email address.
Enter the correct password.
Click the Login button.
Verify that the account dashboard appears.
The expected result is that the user successfully logs in and reaches the dashboard.
However, testing only a successful login is not enough. Testers should also check what happens when users enter incorrect passwords, leave required fields empty, or try to log in using blocked accounts. These are called negative test scenarios. Combining positive and negative scenarios gives better coverage of the application's behaviour.
Step 4: Set Up the Test Environment
The test environment is where the application is tested. It should contain the software build, configurations, test accounts, databases, and connected services required for execution.
When testing an e-commerce application, the environment may need:
A working version of the shopping website
Customer accounts
Products with different stock quantities
A payment gateway test environment
An order management system
Supported browsers and devices
An incomplete environment can prevent test execution or produce results that do not reflect real application defects.
Step 5: Prepare Test Data
Test data is the information testers use to run their test cases. Good test data covers normal situations, invalid inputs, and edge cases.
For the e-commerce application, that could mean:
Customer accounts with different roles and order histories
Products with different stock levels, including one with zero stock
Test cards that succeed and test cards that are declined
Incomplete or incorrectly formatted delivery details
If you use copies of real customer data, mask personal details first. Many teams prefer synthetic data because it avoids privacy problems.
Step 6: Execute the Test Cases
Once the environment and data are ready, testers execute the prepared test cases. During execution, they compare the actual application behaviour with the expected results. Each test case receives a status based on its outcome:
Pass: the application behaves as expected.
Fail: the actual result differs from the expected result.
Blocked: testing cannot continue because of an issue or dependency.
Not Run: the test case has not yet been executed.
Suppose a tester completes payment for an online order. The application displays a payment success message, but the order is missing from the customer's order history. The test case should fail, because the complete expected result has not been achieved. Testers must check all relevant conditions rather than relying on one successful screen or message.
Step 7: Report Defects and Retest Fixes
When testers discover unexpected behaviour, they investigate and document it in a defect report. A useful defect report explains the problem clearly enough for developers to reproduce it. It usually includes the defect title, environment, test steps, expected result, actual result, and supporting evidence.
After the issue is fixed, the tester executes the relevant test case again. This is called retesting. The team may also perform regression testing to check whether the changes have affected other features that previously worked correctly.
Step 8: Review the Test Results
After executing the planned tests, the team reviews the results to determine whether testing objectives have been met. The review may consider:
The number of passed and failed test cases
Coverage of important requirements
Unresolved defects
Features that could not be tested
Known risks
Agreed exit criteria
A project may require all critical checkout scenarios to pass before release. If an important payment defect remains unresolved, the team should communicate the risk rather than treating testing as complete simply because most test cases passed. The final testing summary helps stakeholders make informed release decisions.
Real-World Example of System Testing
To understand system testing better, consider a complete checkout process on an e-commerce website. Suppose a customer wants to buy a pair of shoes. The website allows the customer to search for products, add items to a cart, enter delivery details, make payments, and view order history. These features are connected, so testing them separately is not enough. A system tester needs to verify that the complete purchase process works correctly.
Understand the requirements
Assume the application has the following requirements:
Customers can purchase products that are available in stock.
Successful payments must create confirmed orders.
Inventory must decrease after an order is confirmed.
Failed payments must not create confirmed orders.
Customers must receive an order confirmation.
Retrying a payment must not create duplicate orders or charges.
These requirements define the expected behaviour.
Identify system test scenarios
The tester can now identify situations that need to be checked. Positive scenarios include:
Purchasing an available product
Completing payment with valid payment details
Receiving an order confirmation
Verifying that the order appears in order history
Checking whether inventory updates correctly
Negative scenarios include:
Attempting to purchase an out-of-stock product
Completing checkout with a declined payment
Losing the payment service connection
Retrying a payment after a timeout
Submitting incomplete delivery information
These scenarios help testers evaluate the application under both expected and unexpected conditions.
Write system testing test cases
The next step is to convert the scenarios into test cases. The following examples show how system testing test cases can be documented.
Test Case ID | Test Scenario | Expected Result |
ST-001 | Purchase an available product using valid payment details | Payment succeeds, the order is created, and inventory updates |
ST-002 | Attempt checkout with declined payment | No confirmed order is created, and inventory remains unchanged |
ST-003 | Try purchasing an out-of-stock product | The application prevents checkout and displays an appropriate message |
ST-004 | Complete an order and check confirmation | The customer receives the correct order details |
ST-005 | Retry checkout after a payment timeout | No duplicate order or payment is created |
ST-006 | Open order history after a successful purchase | The confirmed order appears with the correct information |
These test cases cover important interactions between payment processing, inventory, order management, and customer accounts.
Execute a sample test case
Take test case ST-001: verify successful product checkout. Before execution, the tester confirms that the customer account is active, the product is available, and the payment test environment is working. The tester then performs these steps:
Open the shopping website.
Log in using a valid customer account.
Search for an available product.
Add the product to the cart.
Proceed to checkout.
Enter valid shipping information.
Complete payment using valid test payment details.
Verify the order confirmation.
Open the customer's order history.
Check whether the product inventory has decreased.
Expected result: the payment succeeds, the order is confirmed, and the inventory decreases by the purchased quantity.
Now suppose the payment succeeds and the order appears in the customer's account, but the inventory quantity does not change. The tester marks the test case as failed, because the application has not met all the requirements.
How to report the defect
The tester should now document the issue. This is a hypothetical defect created for learning purposes.
Defect ID: BUG-001
Defect title: Product inventory does not update after successful checkout
Related test case: ST-001
Severity: High
Steps to reproduce: log in using a valid customer account, add an available product to the cart, complete checkout successfully, then check the inventory quantity.
Expected result: the inventory decreases after the order is confirmed.
Actual result: the order is confirmed, but the inventory quantity remains unchanged.
Impact: customers may be able to purchase products that are no longer available.
Once developers fix the problem, the tester should repeat the failed test and check related inventory scenarios. This example shows how system testing connects requirements, test scenarios, test cases, execution results, and defect reporting.
Difference Between System Testing, Integration Testing, and Acceptance Testing
System testing, integration testing, and acceptance testing evaluate software from different perspectives. The same application workflow may be examined at more than one testing level, so it helps to know how they differ.
System testing vs integration testing
Integration testing focuses on communication and data exchange between connected components. A tester may verify whether the payment gateway sends the correct transaction response to the order management service.
System testing has a broader scope. Instead of checking only the connection between payment and order management, the tester verifies the complete purchase process. This includes payment confirmation, order creation, inventory updates, and order history.
Integration testing: checks whether connected components interact correctly.
System testing: checks whether the complete application behaves according to its requirements.
System testing vs system integration testing (SIT)
These two names sound alike but mean different things. System integration testing focuses on how your application connects to other external systems, such as a payment provider, a CRM, or an ERP platform. System testing covers your whole application, including those connections as one part of the picture.
System testing vs acceptance testing
System testing checks whether the integrated application meets its specified requirements. It is commonly performed by QA engineers and testing specialists.
Acceptance testing checks whether the software satisfies agreed acceptance criteria and is suitable for its intended use. It may involve customers, product owners, business representatives, or other authorised stakeholders.
System testing may verify that a discount is calculated according to the specified rules. Acceptance testing may determine whether the overall discount process supports the business's intended promotion. The difference is mainly in the testing objective and the acceptance criteria. Passing system testing does not automatically mean the product has been accepted by the business.
Common Challenges in System Testing
Testing a complete application can be more complicated than testing individual features. Large applications may contain many connected services, user roles, devices, and possible workflows. Here are some challenges testers commonly face.
Incomplete or unclear requirements
When requirements are unclear, testers may struggle to decide what the expected result is. A requirement may say that customers should receive an order confirmation without explaining what happens if the notification service is unavailable. Testers should clarify such conditions before writing test cases.
Unstable test environments
System testing depends on several components working together. If a database, server, or external service becomes unavailable, testing may be interrupted. Teams should verify environment readiness before execution and record environment-related issues separately.
Insufficient test data
Some scenarios need specific test data. Testing a banking application may require accounts with insufficient balances, transaction limits, or different permission levels. Without suitable data, testers may miss important conditions. Reusable test data helps improve coverage.
Large number of test scenarios
A complete application can have hundreds or thousands of possible test scenarios, and executing every combination is rarely practical. Testers should prioritise scenarios based on business importance, application complexity, potential impact, and known risks.
Difficult-to-reproduce defects
Some defects appear only under particular conditions. A payment issue may occur only when the network disconnects right after the payment provider processes a transaction. Recording exact steps, timestamps, logs, and test data makes such defects easier to investigate.
Best Practices for Effective System Testing
System testing becomes more useful when testers focus on meaningful scenarios rather than simply increasing the number of test cases. The following practices can help:
Understand the requirements before designing tests.
Focus on complete workflows and how connected features behave together.
Include positive and negative scenarios, such as successful actions, invalid inputs, and unexpected failures.
Prepare realistic test data that represents different users and conditions.
Write clear expected results that explain exactly what should happen after each action.
Prioritise important features, especially workflows that affect security, payments, and essential business operations.
Document defects properly so developers can reproduce them.
Retest after fixes to verify that reported problems are resolved.
Run regression tests to check that changes haven't affected existing functionality.
One useful habit is to ask what happens when an action succeeds, fails, or gets interrupted. When testing an online payment, don't check only successful transactions. Also consider declined payments, repeated clicks, timeouts, and interrupted connections. These conditions often reveal problems that would otherwise go unnoticed.
Manual vs Automated System Testing
System testing can be performed manually, through automation, or using both approaches. Most teams use a mix.
Automation suits repeated work: regression suites, load tests, compatibility runs, and API checks.
Manual testing suits work that needs judgment: exploratory testing, usability checks, and one-off scenarios.
A simple rule: automate what you will run many times, and keep people for the work that needs curiosity and judgment.
System Testing in Agile and CI/CD
System testing doesn't have to be one large phase at the end of a project. Many teams spread it across the delivery pipeline:
On every build: quick smoke tests on the most important workflows.
Every night: a larger automated regression run.
Before each release: full end-to-end checks, plus performance, security, and compatibility testing.
This gives developers faster feedback and keeps problems from piling up until the end.
Metrics Worth Tracking
A few simple numbers show how system testing is going.
Test pass rate: passed tests divided by executed tests, times 100.
Execution progress: executed tests divided by planned tests, times 100.
Requirements coverage: requirements with at least one test, divided by all requirements, times 100.
Defect arrival rate: new defects found per day or per build. When it drops close to zero, testing has probably covered most of what matters.
Defect leakage: defects found after release, divided by all defects found, times 100. Lower is better.
Tools Used for System Testing
The tools depend on the application's technology, requirements, and testing objectives. Some commonly used tools include:
Jira: helps teams document defects, track issues, and manage testing activities.
TestRail: supports test case management, execution tracking, and test reporting.
Postman: lets testers send API requests and verify responses, which is useful for checking the APIs behind system workflows.
Selenium: supports browser automation for web application testing.
Playwright: automates browser-based testing and helps verify application workflows.
Apache JMeter: supports load and performance testing.
These tools serve different purposes. Jira is mainly for issue tracking, while JMeter is for performance-related testing. For beginners, learning how to understand requirements, write test cases, execute tests, and report defects matters more than learning every tool. Once these fundamentals are clear, working with testing tools becomes easier.
Practical System Testing Exercise for Beginners
Let's try a small exercise. Imagine you are testing an online doctor appointment booking application. It allows patients to log in, search for doctors, select appointment slots, confirm bookings, and cancel appointments.
Your task is to identify five system test scenarios. Think about both successful actions and situations where something might go wrong. Here are some samples:
Scenario 1, successful appointment booking: verify that a patient can select an available appointment slot and receive a booking confirmation.
Scenario 2, double booking prevention: verify that two patients cannot book the same appointment slot when double booking is not allowed.
Scenario 3, appointment cancellation: verify that a patient can cancel an appointment and that the booking status updates correctly.
Scenario 4, session expiration: verify that the application handles an expired login session during booking without creating an unintended appointment.
Scenario 5, confirmation failure: verify that if the confirmation message fails to send, the booking still shows correctly in the patient's account, and retrying does not create a duplicate appointment.
Now choose any one scenario and write a complete test case. Include the preconditions, test data, execution steps, expected result, actual result, and final status. This exercise will help you practise turning application requirements into test scenarios and test cases.
Final Thoughts
System testing checks whether a complete software application meets its requirements and works correctly when different features interact. It helps testers identify issues in real user workflows, including problems that may not appear during unit or integration testing.
If you are learning manual testing, start with a familiar application such as an e-commerce website or an appointment booking system. Write a few test scenarios, convert them into test cases, and practise documenting the results. These basic activities provide a foundation for working on real software testing projects.
Frequently Asked Questions
What is system testing in simple words?
System testing checks a complete software application to verify that its features work together and meet the specified requirements.
What is an example of system testing?
Testing an online shopping process from login and product selection to payment, order confirmation, and inventory updates is an example of system testing.
Is system testing black-box or white-box testing?
System testing commonly uses black-box techniques to verify application behaviour. White-box techniques may also support some system-level testing activities.
Who performs system testing?
System testing is commonly performed by QA engineers and software testers. Developers and specialised testing professionals may also take part.
Is system testing manual or automated?
System testing can be performed manually, through automation, or using a combination of both approaches.
What is the difference between system testing and UAT?
System testing verifies the application against system requirements. User acceptance testing checks whether it meets agreed business and user acceptance criteria.
What is the difference between system testing and system integration testing?
System integration testing focuses on how your application connects to other external systems. System testing covers the whole application, including those connections.
When should system testing start?
System testing generally starts after the required components have been integrated and the application meets the agreed entry criteria.
When is system testing complete?
When the agreed exit criteria are met: planned tests have been run, no critical defects remain open, regression tests have passed, and remaining risks are documented.
What are the main types of system testing?
Common types include functional, regression, smoke, performance, load, stress, security, usability, accessibility, compatibility, recovery, and reliability testing.