Test Levels and Test Types
Testing needs structure to cover everything without wasting effort on duplication. Test levels are about where and when you test - from a single function up to the whole integrated system. Test types are about what you're testing for - does it work, is it fast, is it secure? This topic also covers what happens right after a defect gets fixed.
~10 min read
The core ideas, explained
Component Testing (Unit Testing)
The smallest test level, focused on the smallest testable parts of the software - modules, objects, classes, or individual functions - tested in isolation from the rest of the system. Usually performed by developers, who use mock objects or stubs to stand in for dependencies that aren't available yet or aren't the focus of the test.
Testing a single JavaScript function that totals the prices of items in a shopping cart, confirming it adds the numbers correctly - with no database, UI, or network involved at all.
Component Integration Testing
Focuses on the interactions and interfaces between components that have already each passed their own component testing - checking that data actually flows correctly from one unit-tested piece to another, not just that each piece works alone.
Confirming that the shopping cart function correctly retrieves the current item price from the product database module, rather than a stale or default value.
System Testing
Focuses on the behavior and capabilities of the entire integrated system, tested against its functional and non-functional requirements in an environment that closely mirrors production - the first level where the application is evaluated as a whole, rather than piece by piece.
Logging into the e-commerce site, adding items to the cart, and completing checkout end-to-end, to confirm the whole application works the way a real user would experience it.
System Integration Testing (SIT)
Focuses specifically on the interactions between the system under test and independent external systems it depends on - third-party APIs, external databases, or other services the team doesn't control - as opposed to internal seams, which component integration testing already covers.
Confirming the e-commerce application successfully sends payment details to a third-party gateway like Stripe or PayPal, and correctly handles whatever response comes back.
Acceptance Testing
Validates that the system meets real user needs and business requirements, and is genuinely ready for deployment - the last level before release. It splits into several sub-forms: User Acceptance Testing (UAT), where real users judge whether the system is fit for their purposes; Operational Acceptance Testing (OAT), where administrators check backup/restore, maintenance, and security tasks; Contractual and Regulatory Acceptance Testing, confirming compliance with a specific contract or law; and Alpha/Beta Testing, where potential users try the system either at the developer's site (alpha) or in their own environment (beta).
A retailer invites a group of employees to try the new checkout flow at the company office before launch (alpha testing), then rolls it out to a small set of existing customers using their own devices at home (beta testing) - both feeding into the final sign-off.
Functional Testing ("what the system does")
Evaluates the specific functions the system should perform, based on requirements or specifications. It asks whether a feature behaves the way it's supposed to - not how fast, secure, or usable it is.
Verifying that a user genuinely cannot log in when they enter an incorrect password, and gets an appropriate error message instead of being let through.
Non-Functional Testing ("how well the system does it")
Evaluates characteristics like performance, usability, reliability, security, and portability - qualities of the system that sit alongside its functional behavior, rather than the behavior itself.
Checking whether the login page still loads in under two seconds when 1,000 concurrent users are hitting it at once - a performance test, not a functional one.
White-box Testing (Structure-based)
Designs tests based on the internal structure, architecture, or code of the software, which means it requires knowledge of how the software is actually built - not just what it's supposed to do.
Writing tests that ensure every single if/else branch in a function has been executed at least once (statement coverage) - something you can only design by reading the code itself.
Black-box Testing (Specification-based)
Designs tests based purely on an analysis of external specifications - requirements, user stories, specifications - without any knowledge of, or reference to, the internal code structure.
Choosing boundary values to enter into a text field just by reading the requirements document, with no idea what validation logic actually sits behind that field.
Confirmation Testing (Re-testing)
After a defect is reported and supposedly fixed, confirmation testing re-runs the exact same test - the same inputs, the same steps - that originally failed, purely to confirm that specific defect is now gone.
Yesterday, clicking "Submit" crashed the app. Today the developer says it's fixed, so you click "Submit" again, the same way, to see if it still crashes.
Regression Testing
Re-runs tests in areas of the software that were already working, to make sure a recent code change - often the same fix confirmation testing just checked - didn't accidentally break something unrelated. Because it's repeated so often with little variation, a regression suite is one of the best candidates for automation.
After the "Submit" button fix, you also test the "Cancel" button and the navigation menu, to make sure the fix didn't introduce a new, unrelated problem elsewhere.
Key points to remember
- Component integration testing checks the seams inside your own software; system integration testing checks the seams between your software and the outside world.
- UAT is for business users - does it solve the business problem? OAT is for IT administrators - can we back it up, restore it, and maintain it?
- Black-box testing looks at the requirements; white-box testing looks at the code itself.
- Confirmation testing checks that the specific reported fix actually works; regression testing checks that everything else still does too.
- Test levels and test types are independent dimensions - almost any test type can be applied at almost any test level (e.g. functional component testing, non-functional system testing, white-box integration testing).
Summary
Testing is organized along two independent dimensions. Test levels scope the test - from an isolated component up to full user acceptance - while test types scope the focus of the test - functionality, performance, internal structure, and more. Once code changes, confirmation testing verifies the specific fix, and regression testing protects everything else from unintended side-effects.
| Concept | One-line memory hook |
|---|---|
| Component testing | Testing the smallest pieces in isolation (unit testing) |
| Component integration | Testing how your own internal pieces talk to each other |
| System testing | Testing the whole completed application at once |
| System integration | Testing how the application talks to external systems |
| Acceptance testing | The user/business confirms it's ready for the real world |
| Functional testing | Testing what the system does (features) |
| Non-functional testing | Testing how well the system does it (speed, usability) |
| Black-box testing | Testing from specs; the code stays invisible |
| White-box testing | Testing from code; looking under the hood |
| Confirmation testing | Did the developer actually fix the bug? |
| Regression testing | Did the fix break anything else? |
Check your understanding
10 quick questions - click an option to see if you got it right.