What is system testing?

System testing checks the complete, integrated product against its requirements. It looks at the whole system the way users will get it, covering features, end-to-end journeys and key non-functional areas such as performance, security and recovery, before acceptance testing and release.

How is system testing different from integration testing?

Integration testing checks that parts of the system work together, such as modules, services and third parties. System testing checks the finished whole against its requirements. Integration usually comes first; system testing follows once everything is connected.

How is system testing different from UAT?

System testing is done by QA engineers to prove the product meets its requirements. UAT is done by business users to decide whether it is right for the business. A good system test means UAT starts on a stable product.

What are entry and exit criteria?

Entry criteria are the conditions that must be true before system testing starts, such as a stable build and a ready environment. Exit criteria are the conditions for finishing, such as all critical tests passed and no open critical defects. We agree both with you before testing begins.

What is a requirements traceability matrix (RTM)?

An RTM maps every requirement to the tests that cover it and their latest results. It shows at a glance which requirements are proven, which have problems and which are not yet tested.

Is system testing manual or automated?

Usually both. New features, end-to-end journeys and exploratory checks are often manual. Stable regression tests run well as automated suites with tools such as Playwright, Selenium and Postman.

Do you include performance and security testing?

We include basic performance and baseline security checks in every system test cycle, so obvious problems are caught early. For full load testing or penetration testing, we recommend our dedicated performance and security services.

Can you test installation and upgrades?

Yes. We test fresh installs, upgrades from earlier versions, configuration options and, where relevant, rollback and uninstall, with data checked before and after.

How long does system testing take?

It depends on the size of the product and how stable it is. The scope planner on this page gives a rough guide; we confirm the real plan after reviewing your requirements.

What do you need from us?

Requirements or user stories, a stable build in a test environment, test accounts for each role, and a contact who can answer questions about expected behaviour.

What happens if the system isn’t ready?

If entry criteria aren’t met, we say so early and suggest what to fix first, such as a smoke-tested build or missing data. We can start on test design while the system is finished.

Do you test multi-tenant and role-based systems?

Yes. We test every role and permission level, and check that data stays separate between users, teams and tenants.

A system test plan, test cases, a traceability matrix, bug reports, regression results and an exit report with a clear recommendation.

How do we get started?

Book a call or send the form on this page. We start with a free one-week proof of concept: we review your requirements, draft the system test plan and test your most important end-to-end journey.

System Testing Services

Every feature can pass its own tests and the product as a whole can still let users down. System testing is where the complete product is put to the test.

We test your finished, integrated product against its requirements: every feature, every end-to-end journey and the key checks around speed, security and recovery. You get clear evidence of what works, traced to each requirement, and an honest view of whether it is ready.

Get in touch Plan your system test

Requirements to exit report
End-to-end journeys
Full traceability
Free one-week POC

What we do

Functional system testingAgainst the spec End-to-end flowsWhole journeys RegressionAfter every change Roles & permissionsWho can do what Installation & upgradeSet-up and change Recovery & failoverWhen things go wrong Performance checksEarly warning Security checksBaseline safety Cross-platform system checksEverywhere it runs Test documentationEvidence

[ Why system testing ]

The first time anyone tests the whole product shouldn’t be launch day

Developers test their code. Teams test their features. But somebody has to test the finished product as one system, with real roles, real data and complete journeys, against what was actually promised. That is system testing. It is the stage where missing requirements, broken hand-offs and slow screens show up, while there is still time to fix them, and before business users spend their time on UAT.

Testing how systems connect? See integration testing and SIT →

The whole product, tested as one

Not just features in isolation, but the complete system your users will get.

Requirements you can prove

Every requirement traced to tests and results.

A clear go or no-go

Entry and exit criteria agreed up front, so readiness is a fact, not an opinion.

Ready for UAT

Business users start acceptance on a stable system, not a list of known bugs.

[ What we test ]

Ten parts of a complete system test

From every requirement to the exit report. Each one lists what we test, when you need it and the problem it prevents.

Requirements-based functional system testing

Against the spec

The complete product tested against its requirements, feature by feature, so you know exactly what works and what doesn’t before anyone else uses it.

What we test

Every requirement mapped to one or more system tests
Positive, negative and boundary cases
Business rules, calculations and workflows
Results traced back to each requirement

When you need it

Once the product is feature-complete and integrated.

The problem it preventsRequirements that were built, but not the way they were written

End-to-end business flow testing

Whole journeys

Complete journeys from the first click to the final result, across every screen, service and email involved.

What we test

Journeys such as sign-up to first purchase, or order to delivery
Hand-offs between modules and back-office steps
Notifications, documents and emails at each stage
Realistic data and timing, not just the happy path

When you need it

Before every major release and go-live.

The problem it preventsEvery step works on its own, but the journey breaks in the middle

Full-system regression testing

After every change

View service

A planned run of the system tests that matter most, to prove that new work hasn’t broken what already worked.

What we test

Risk-based selection of regression tests per release
Core journeys on every cycle
Deeper checks around changed areas
Suite kept current as the product grows

When you need it

Before each release, and after large fixes or refactors.

The problem it preventsAn old feature quietly breaking in the new release

Roles, permissions & data

Who can do what

The same system looks different to every role. We test each one, and the data each one can see and change.

What we test

Every role and permission level in scope
Data visibility between users, teams and tenants
Create, edit, delete and approval rules per role
Audit trails for sensitive actions

When you need it

For multi-role, multi-tenant and regulated products.

The problem it preventsA user seeing or changing data they should never reach

Installation, upgrade & configuration

Set-up and change

We test that the system installs, upgrades and configures correctly in the environments your customers or teams really use.

What we test

Fresh install and upgrade from earlier versions
Configuration options, feature flags and settings
Data kept safe and correct through upgrades
Rollback and uninstall where relevant

When you need it

Before each version release, and for on-premise or self-hosted products.

The problem it preventsAn upgrade that works in staging but breaks a customer’s data

Recovery, failover & error handling

When things go wrong

Systems fail. We check that yours fails safely, tells people what happened and recovers without losing data.

What we test

Timeouts, lost connections and service outages
Clear, useful error messages
Restarts, retries and recovery without data loss
Failover and backup restore, with your operations team

When you need it

Before go-live, and after infrastructure changes.

The problem it preventsA small outage turning into lost orders or corrupted records

Basic performance & load checks

Early warning

View service

A quick check of response times and behaviour under realistic load, as part of system testing, so obvious slowdowns don’t reach production.

What we test

Response times on key screens and APIs
A realistic number of users at once
Slow queries and heavy pages flagged
Results compared release to release

When you need it

In every system test cycle. For full load testing, see our performance testing.

The problem it preventsA release that passes every test but is too slow to use

Security & compliance checks

Baseline safety

View service

Baseline security and compliance checks as part of system testing, so the most common problems are caught early.

What we test

Authentication, sessions and password rules
Common web risks such as injection and broken access control
Sensitive data handling and masking
Checks against your compliance requirements

When you need it

In every system test cycle. For in-depth work, see our security testing.

The problem it preventsBasic security gaps reaching production

Cross-platform system checks

Everywhere it runs

View service

The complete system checked on the browsers, devices and operating systems your users have.

What we test

Main journeys on Chrome, Safari, Edge and Firefox
Real iOS and Android devices
Desktop operating systems where relevant
Device clouds such as BrowserStack for breadth

When you need it

Before releases and whenever you add a platform.

The problem it preventsA product that only really works on the testers’ own machines

System test plan, RTM & exit reports

Evidence

The documents that show what was tested, against which requirement, and whether the system is ready to move on.

What we test

System test plan with entry and exit criteria
Requirements traceability matrix (RTM)
Defect summaries by severity and area
Exit report with a clear recommendation

When you need it

For every system test cycle, and essential for audits and client hand-overs.

The problem it preventsReleasing without knowing what was tested, or why it was approved

[ Where system testing fits ]

Four levels of testing, four different questions

System testing sits between integration and acceptance. And every cycle ends with an exit report like the one on the right.

Level	Question it answers	Who does it	What it covers
Unit testing	Does this piece of code work?	Developers	Single functions and classes
Integration testing	Do the parts work together?	QA and developers	Modules, services and third parties
System testing	Does the complete product meet its requirements?	Independent QA	The whole system, end to end
Acceptance testing (UAT)	Is it right for the business?	Business users	Real tasks and processes

Sample exit reportReady with conditions

Cycle: Release 3.2 · system test cycle 2
Executed: 412 of 420 planned tests (98%)
Passed: 396 · Failed 16 · Blocked 8
Open defects: 0 critical · 2 high · 9 medium
Requirements: All 128 covered; 3 with open high defects
Recommendation: Ready for UAT once the 2 high defects are fixed and retested

Example only. Real reports reflect your requirements and results.

[ How we work ]

Six steps from requirements to exit report

Entry and exit criteria agreed before we start, so “ready” means the same thing to everyone.

Step 1 of 6
Review requirements

Specs, user stories and risks reviewed with your team; gaps flagged early.

You getRequirements review notes
Step 2 of 6
Plan the system test

Scope, approach, environments, data and entry and exit criteria agreed.

You getSystem test plan
Step 3 of 6
Design the tests

Test cases and end-to-end scenarios, mapped to every requirement.

You getTest casesTraceability matrix
Step 4 of 6
Run the cycles

Functional, end-to-end and key non-functional checks, with daily updates.

You getBug reportsDaily progress
Step 5 of 6
Retest and regress

Fixes retested and regression run on the full system.

You getRegression results
Step 6 of 6
Report and exit

Results against exit criteria and a clear recommendation.

You getExit report

Free one-week POCWe review your requirements, draft the system test plan and test your most important journey.
Independent viewTesters who didn’t build it, reporting honestly against what was promised.
In your toolsTest cases and bugs in your Jira, Azure DevOps or test management tool.

[ Tools ]