What is system testing? Definition, examples, and why it matters

ystem testing is the stage where you test a complete, integrated software system against its specified requirements. Where unit and integration testing check the parts, system testing checks the whole product working together. It comes after those stages and before user acceptance testing (UAT), as the last internal checkpoint before real users see the software.

At a glance

• System testing checks the complete, integrated system against its requirements, after unit and integration testing
• It comes before user acceptance testing (UAT) and is usually run by QA testers
• Functional system testing checks the system does what was specified; non-functional covers performance, security, stress, usability and scalability
• A short checklist (core user journeys, error handling, integrations, notifications) keeps coverage focused
• Getting started doesn't need heavy process: plan what to test, test it, report what you find, retest the fixes, and sign off

The rest of this guide covers the definition and an example, how system testing compares with other types of testing, the main types, and how to get started.

What is system testing?

System testing is the process of testing a complete, integrated software system to verify that it meets specified requirements. The ISTQB Foundation syllabus puts it the same way: system testing "focuses on the overall behavior and capabilities of an entire system or product". It checks whether your entire product works as a whole in the way it should. It isn’t any more complicated than that – even though some tools and testing resources make it feel more complex with lots of jargon and complicated explanations.

You can think of it as the stage when everything comes together. Once you’ve tested the individual parts of your product or software individually, system testing makes sure that they all work together as they were designed to do.

System testing example: e-commerce website

If you have an e-commerce site, you might have tested that the login screen, payment system and shopping cart functionalities all work properly – but you then need to do system testing to make sure that they all work smoothly together.

So your system testing would look at how it all works together, which might include things like:

• Checking everything works when there are lots of users on the site at the same time.
• Making sure that the inventory updates properly after items are sold.
• Checking that confirmation and shipping emails are sent after a purchase is made.

How is system testing different from other types of testing?

While the premise of system testing isn’t complex, it can sometimes be helpful to know what something doesn’t do, in order to better understand what it does do. So, with that in mind, here’s what system testing doesn’t cover:

• Unit testing: System testing doesn’t focus on testing individual units in isolation. That’s the job of unit testing, which ensures that the smallest testable parts of the application (called the units) work properly on their own.
• Component testing: This is essentially the next level up from unit testing, testing a module or feature that’s made up of multiple units.
• Integration testing: Testing how specific parts work together, making sure that multiple components talk to each other in the way they’re supposed to.

When it comes to system testing vs unit testing, then, the main difference is the level of focus: unit testing (and component testing) checks individual parts of the software to make sure each function or component works on its own, while system testing looks at the whole software system to ensure all parts work together properly. Unit, component and integration testing are all typically done by developers as part of the software development process.

All of these types of testing, as well as system testing, are done before user acceptance testing. This comes after the internal testing done by your team, when the QA team thinks the product or software is ready for your client or end user.

System testing also shouldn’t be confused with software testing, which is a more general term for the entire process of testing software, while system testing is one of the component parts, along with unit testing and component testing.

Here’s how the levels compare side by side:

Why is system testing important?

System testing matters in any test plan because it makes sure that all the parts of your system work together as expected. When you do system testing, you can check that the entire system behaves as intended as a whole. It helps you to identify any potential problems that might not have been found during earlier phases of testing like unit or integration testing, reducing the risk of bugs or failures after you deploy.

Benefits and limitations of system testing

The benefits of system testing include the following:

• Comprehensive: System testing verifies that the entire system works as a whole, and that it meets all specified requirements.
• Identifies bugs pre-launch: It’s common for things to get missed during earlier rounds of testing, so system testing will help you to catch anything before you launch.
• Quality checking: It ensures that your product is stable, reliable and ready for deployment, leading to fewer post-launch issues, and increased customer satisfaction.
• Real-world testing: System testing should be carried out in conditions as close as possible to the real world, so the results reflect how the software will behave in production. This also means it helps you to prepare for user acceptance testing.

But there are also some potential challenges you might face with system testing:

• Time-consuming: Comprehensive system testing can take time, especially if your system is large or complex.
• Complex test case design: Because you’re testing the entire system, there are many test cases needed – which means you need to stay organized for it to be effective.
• Risk of incomplete coverage: Again, because the scope for system testing is wide, there’s the risk of missing edge cases.
• Dependence on earlier stages: If there were any gaps in your previous testing phases, these may be carried over into your system testing.

These trade-offs are well documented on the automation side too. Martin Fowler’s test pyramid recommends lots of small unit tests and "very few high-level tests that test your application from end to end", and Google’s testing blog suggests a 70/20/10 split across unit, integration and end-to-end tests, partly because a failing whole-system test is harder to trace back to a cause. The lesson carries over to manual system testing: keep it focused on what only a whole-system test can tell you.

What are the types of system testing?

System testing is a broad umbrella term – there are various different types of tests that can be categorized as system testing. These can be broken down into functional and non-functional testing.

Functional testing checks if the system works according to the requirements, for example, checking whether the login feature works. It also includes regression testing. This checks that new features haven’t broken existing functionality, catching bugs that may have been unintentionally introduced. It’s often automated but can also be manual, and some teams consider it to be part of their system testing – but it can also be thought of as standalone testing.

Non-functional testing checks important aspects like performance, security and speed. These tests include:

• Usability testing: This checks how user-friendly and intuitive the user interface (UI) is. It can happen as part of product development.
• Stress testing: This tests the system's stability under extreme conditions, such as high traffic or resource depletion.
• Performance testing: This checks how well your software or system works under different conditions, making sure it can handle the demands of real users, heavy traffic, and processing lots of data.
• Security testing: This testing is fairly self-explanatory. The aim is to identify vulnerabilities and ensure that a software system is secure from potential threats or attacks.
• Scalability testing: This checks that your application can handle increases in load and traffic.

How does system testing fit in with your wider testing plan?

It’s best to do system testing after you’ve completed unit testing (when all individual units of the system have been tested separately to make sure they work correctly) and integration testing (when you’ve checked that the different components or modules work together as expected).

Once these steps have been taken, you can carry out system testing, to look at the entire system as a whole to make sure that all the parts work together as you expect them to.

System testing should come before user acceptance testing (UAT), which is when your client or real users test the software to ensure it meets the requirements of the real people using it.

You’ll always want to do functional testing as part of your system tests, but it’s not always necessary to do every type of non-functional testing. The decision as to what types of system testing you do should be based on your system's specific needs.

System testing checklist: what to test before release

Before signing off your system tests, it’s worth checking that you’ve covered the most important areas. A basic system testing checklist might include:

• Core user journeys, from start to finish
• Error handling and edge cases
• Performance under realistic load
• Data accuracy and integrity
• Security basics, such as access controls
• Integrations with third-party tools or services
• Notifications, emails, and system messages

This helps ensure your testing stays focused on how the system will actually be used – not just how it’s meant to work on paper.

How to get started with system testing

Remember, system testing doesn’t need to be complicated. Here are the steps you should take to make sure it’s simple, stress-free, and effective.

1. Make a test plan
In other words, you should outline your overall framework and strategy for testing.

2. Write your test scenarios and test cases
A test scenario is a high-level description of functionality to be tested, while a test case is a more detailed set of criteria for testing a feature or functionality.

3. Create test data
Make sure you have the information you need to validate your tests. This might involve creating sample accounts, transactions, or datasets.

4. Create the test environment
Remember, the test environment should mirror the production environment as closely as possible to ensure realistic testing conditions.

5. Conduct the tests
Run your tests to check if the system performs the intended functions correctly. You might, for example, test whether users can log in or make purchases as expected.

6. Document and report issues
As you test, document any issues or bugs you encounter. Provide detailed steps, screenshots, or logs to help the development team identify and fix the problem. You may want to use a bug tracking tool to log issues.

7. Test again
Once the development team addresses the bugs, retest the system to ensure the issues were fixed and no new problems were introduced.

8. Final testing and sign off
If the issues have been fixed, you can sign off the system for release. But if the issues persist – or if you discover any new issues – you’ll need to keep tweaking and testing until the problems have been resolved.

Manage your system testing with Testpad

There are lots of different things you can test during your system testing, which means that you could quickly lose track of both the tests you need to complete and their results. So you might be considering a test management tool to help you stay on top of things.

We recommend keeping things simple – because there’s really no need to make testing more complicated than it needs to be. Testpad is a checklist-based testing tool: each test is a line of plain text, each test run is a column, and the resulting grid shows your coverage at a glance.

Some of the key features include:

• Plain text tests: each test is a single line, so anyone on the team can read and run the plan, including non-technical users.
• Keyboard-driven editor: type hundreds of test prompts in minutes, with free-form test plans so you can test however you like to do it.
• Guest testers: invite guests to run tests without a login, useful extra hands during a big system test.
• Easy reuse: copy a script (a test plan) from the last release and edit the copy for the next round of testing.
• Report view: every script and folder has a Report view you can share as a link, so anyone can see how far testing has got.

If you want quick and easy system testing, Testpad could be the tool for you. Write and organize your tests fast, get through more testing, and share a report link so anyone can check progress at a glance. If you’re ready to kickstart your system testing, why not try our 30-day free trial today?

System testing FAQs

What is the main goal of system testing?

The goal of system testing is to check that the complete software system works correctly as a whole and meets the specified requirements.

Who performs system testing?

System testing is usually carried out by QA testers or testing teams to provide an independent view of the system, although in smaller teams it may also be performed by developers or cross-functional team members.

Is system testing manual or automated?

It can be either. Many teams use a mix of manual and automated system testing, depending on the size of the system and the risks involved.

When should system testing be done?

System testing should take place after unit and integration testing, but before user acceptance testing.

If you liked this article, consider sharing