System testing
Unit testing checks a function. Integration testing checks a connection between two pieces. System testing checks the whole thing, assembled end to end, against the complete set of requirements the entire application is supposed to meet. It's the first point in the process where the full, real system, not a piece of it, is actually what's under test.
Scope at this level covers both functional behavior, does every feature work correctly as a complete end-to-end flow, and often non-functional characteristics too, performance, security, usability, since the whole system is finally available to test those against rather than a mocked-out piece of it standing in for the real thing.
System testing is typically done by the team that built the software, checking it against its technical requirements. Acceptance testing, which comes right after, is usually done by, or on behalf of, the actual customer or end user, checking the same system against what they actually need, which isn't always identical to what was originally specified.
What gets checked
- Complete end-to-end functional flows, like a full purchase from browsing to confirmation, rather than one piece of it.
- Non-functional characteristics, like performance and security, now that the entire assembled system is actually available to test against.
- Interoperability between every integrated component, not just one connection at a time.
- Compliance with the full set of documented requirements the system was originally built to meet.
Where it shows up
- The stage right after integration testing, once every component is assembled into a complete, deployable system.
- Confirming a full user journey works correctly end to end, not just that its individual pieces connect.
- Running as the gate right before a release moves on to acceptance testing or staging for final sign-off.
- Catching an issue that only appears once every component is actually running together, not in isolation.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Tests the real, fully assembled system, catching a problem that only appears once everything is actually integrated together. | Needs a complete, stable build to run against, it can't start meaningfully until integration is far enough along. |
| Covers both functional and non-functional behavior at once, since the whole system is available to test against. | Slower and more expensive to run than unit or integration testing, and a failure can be harder to trace back to its root cause. |
| Confirms the system meets its documented requirements as a whole, not just that its individual pieces work. | Coming this late in the pyramid means a fundamental issue found here is more expensive to fix than the same issue caught earlier. |
Frequently asked questions
How is system testing different from integration testing?
Integration testing checks that two or more specific components work correctly together. System testing checks the entire, fully assembled application as a whole, against its overall requirements, which is a broader scope than any single integration point.
How is system testing different from acceptance testing?
System testing is usually done by the team that built the software, checking it against its technical requirements. Acceptance testing typically comes right after, done by or on behalf of the actual customer or end user, checking the same system against what they actually need.
Does system testing include non-functional testing?
Often, yes. Since the whole system is assembled and available at this stage, system testing commonly covers performance, security, and usability alongside functional correctness, rather than leaving those entirely to separate, later testing.
How Klarent helps
Klarent's AI agents test complete, end-to-end user flows across an assembled application in a test environment, generating and running the kind of full-system checks that system testing calls for directly from a plain-language description of each flow.