System testing checks a complete, integrated application against its requirements. It treats the software as a finished whole rather than a set of parts, validating that the assembled system behaves the way the specification says it should. It is the level of testing that comes after the pieces have been built and connected, and before users sign off.
Definition: What Is System Testing?#
System testing validates the fully integrated system end to end, from a user or external perspective, against both functional and non-functional requirements. It is usually black-box testing: testers exercise the application through its real interfaces without relying on knowledge of the internal code.
The goal is to answer one question: does the complete system, running as it will in production, do what it is supposed to do?
Where System Testing Fits#
System testing is one level in the standard progression of testing levels. Each level widens the scope:
| Level | Scope | Typical owner |
|---|---|---|
| Unit testing | A single function or component | Developers |
| Integration testing | How modules work together | Developers |
| System testing | The whole integrated application | QA team |
| Acceptance testing | The system against business needs | QA, product, users |
For how these layers balance against each other, see the testing pyramid.
System Testing vs System Integration Testing#
These two are easy to confuse:
- System integration testing (SIT) checks that separate systems or services talk to each other correctly, for example your app, a payment provider, and a database.
- System testing checks the complete product as a single integrated whole against its requirements.
SIT focuses on the seams between systems; system testing focuses on the finished product behaving correctly overall.
Types of System Testing#
System testing covers both functional and non-functional checks. Common types include:
- Functional testing: The features do what the requirements say
- Performance testing: The system meets speed and load targets
- Security testing: Data and access are protected
- Usability testing: The product is workable for real users
- Compatibility testing: It runs across the target browsers, devices, and operating systems
- Recovery testing: The system restores correctly after a failure
- Scalability testing: It holds up as load grows
A Concrete Example#
Take an e-commerce checkout. System testing would verify the full path: a user browses products, adds to cart, applies a discount, pays, and receives an order confirmation, with inventory and email all updating correctly. It would also confirm the page loads within target time, rejects an invalid card safely, and works on mobile. The point is to exercise the assembled system the way a real user would.
System Testing vs End-to-End Testing#
The terms overlap and are often used interchangeably. In practice, system testing is the broader QA level (functional and non-functional, across the whole product), while end-to-end testing usually refers to the automated technique of scripting complete user journeys through the running application. End-to-end tests are one of the main ways teams carry out the functional part of system testing today.
Limitations to Know#
- It runs late. System testing happens after integration, so bugs found here are more expensive to fix than ones caught earlier.
- It is not a substitute for lower levels. Without solid unit and integration tests, system testing becomes the only safety net and slows to a crawl.
- Full-system setup is heavy. A production-like environment, data, and external dependencies all have to be in place.
- Slower feedback. Whole-system runs take longer than unit checks, so they cannot be the place you catch every small regression.
Best Practices#
- Test against requirements, not assumptions. Tie each scenario to a stated requirement or acceptance criterion.
- Cover non-functional needs explicitly. Performance, security, and compatibility are part of system testing, not afterthoughts.
- Use a production-like environment. The closer the test environment is to production, the more the results mean.
- Automate the repeatable paths. Script the stable user journeys so the suite can run on every release instead of by hand.
Conclusion#
System testing is the level where a product is judged as a whole: integrated, running like production, and measured against what it was supposed to do. It sits above unit and integration testing and feeds into acceptance, and it covers both what the system does and how well it does it.
The functional half of system testing is increasingly automated as scripted user journeys, which is also where the maintenance burden lives. If keeping those journeys green through UI changes is the bottleneck, ObserveOne's Autopilot generates Playwright suites from a URL and heals them when selectors drift.