Levels of testing: unit, integration, system, acceptance
Testing happens at four levels, each zooming out a little further. Together they move from a single function to the whole product a customer signs off.
By Quality AboveAll · June 22, 2026 · 7 min read
Where this fits in the wider picture.
Levels of testing: unit, integration, system, acceptance
Senior people on the actual work
No layered account teams between you and the build.
Designed for the bad day
Failover, retries and load behaviour proven before launch.
Threat modelled from the start
Secure defaults, dependency hygiene, and audit trails.
Budgets, not guesses
Latency and throughput targets set and measured.
Usable by everyone
WCAG 2.2 checks built into the pipeline.
The four levels of testing are unit, integration, system, and acceptance, moving from the smallest piece of code to the finished product a user approves.
Why testing has levels
Software is built in layers, so testing checks it in layers too. Each level has a different scope, a different owner, and a different kind of bug it is best at catching. Skipping a level does not remove the risk, it just pushes the bug to a later and more expensive stage.
Read the levels from the inside out: one function, then functions working together, then the whole system, then the user's verdict.
Unit and integration testing
Unit testing checks the smallest testable piece of code, usually a single function or method, in isolation. Developers own it, and it runs fast. A unit test confirms that a discount function returns the right total for a given input.
Integration testing checks that separate units work together. The units may each pass alone but still break when they share data. This is where API and contract testing does heavy lifting, confirming that one module sends exactly what another expects.
- Unit: is this function correct on its own?
- Integration: do these modules agree at the boundary?
Most painful bugs do not live inside a single unit. They live in the gaps between units, which is why integration testing earns its keep.
System and acceptance testing
System testing checks the fully assembled product against the requirements. It tests end-to-end flows the way a user would move through them, including performance and error handling. This is broad functional work, often supported by manual testing and automated end-to-end suites.
Acceptance testing is the final level. Here the question is not does it work, but does it meet the user's needs and the business rules. User acceptance testing puts real or representative users in front of the product, which is the heart of our exploratory and UAT sessions.
A concrete example
Picture an online store adding a wishlist. A unit test checks the function that adds one item to a list. An integration test checks that the wishlist service and the product catalogue exchange the right item ID. A system test walks the full journey: log in, browse, add to wishlist, move to cart, check out. An acceptance test asks a real shopper whether the wishlist actually helps them buy later.
- Unit and integration catch code and interface bugs early.
- System catches broken journeys across the whole product.
- Acceptance confirms the product solves the real problem.
- Wire the fast levels into CI/CD test integration so they run on every change.
One honest caveat: more levels do not mean more confidence if the tests are shallow. A green pipeline with weak assertions can hide real defects, so the quality of each test matters more than the count. Tools like Playwright and Selenium help at the system level, while the ISTQB syllabus defines each level in detail.
At Quality AboveAll, senior testers balance the four levels to fit your risk and budget, often for less than one full-time hire. If you want a clear plan for where to invest, book a free 30-minute testing audit.
Questions about this topic.
What are the four levels of testing?
Unit, integration, system and acceptance. Each checks a different scope, from a single function up to whether the whole product meets the business need, and each catches defects the others cannot.
Who owns each level?
Developers typically own unit and integration tests, QA engineers own system testing, and the business or end users own acceptance. Ownership matters more than the label.
Do we need all four levels?
Most products benefit from all four, but the balance shifts. A library needs deep unit coverage; a workflow-heavy business system needs more at system and acceptance level.
How ready is your product to ship and scale?
Answer 12 questions and get a maturity score across architecture, delivery, quality and security, plus the three things we would fix first. No email required to see your result.
Senior-led QA,embedded in your workflow.
Often less than one full-time hire. Book a free 30-minute testing audit and we'll show you exactly where the risk is hiding.