Test Levels
Unit, integration, system, acceptance. Know what each level proves, who runs it, and what happens when a bug slips through because the wrong level was skipped.
1 The Hook
In 2021, a major NZ bank launched a new feature in their mobile app: instant payments to mates using just a mobile number. The feature had been through full system testing. The QA team had verified that payments went through, notifications fired, and balances updated correctly. It looked solid.
But on launch day, a bug surfaced that nobody had caught: if two customers with the same mobile number (one ported from a rival telco) tried to register, the system silently linked payments to the wrong account. Money was going to strangers. The bank had to freeze the feature within hours.
The root cause? The API integration between the bank’s payment engine and the telco lookup service had never been tested at the integration level. System testing treated the telco lookup as a black box and assumed it worked. Unit testing had checked each component in isolation. But nobody had tested what happened when those two components talked to each other in the real world. The bug lived in the gap between levels.
This is why test levels matter. Each level catches a different class of defect. Skip one, and you create a blind spot.
2 The Rule
ISTQB defines four test levels, each with a different scope, objective, and typical owner.
| Level | What It Tests | Who Typically Does It | What It Proves |
|---|---|---|---|
| Unit testing | Individual components, functions, or methods in isolation. | Developers | The component behaves correctly given valid and invalid inputs. |
| Integration testing | Interfaces and interactions between integrated components or systems. | Developers or testers | Components work together; data flows correctly across boundaries. |
| System testing | The complete, integrated system against specified requirements. | Independent test team | The system as a whole meets its functional and non-functional requirements. |
| Acceptance testing | The system against business needs and user workflows in a realistic environment. | End users, product owners, business analysts | The system is fit for purpose and ready for production use. |
Common Types of Acceptance Testing
- User Acceptance Testing (UAT): The most common form of acceptance testing. Performed by the business/end-users to ensure the software matches their real-world processes. (Sometimes called Business Acceptance Testing).
- Operational Acceptance Testing (OAT): Performed by IT operations/sysadmins to test backup/restore, disaster recovery, and system maintenance.
- Regulatory Acceptance Testing: Verifying the system meets legal or safety standards (e.g., NZ Privacy Act 2020 or Medsafe).
The Test Team’s Role in UAT
During UAT, the professional test team typically shifts from "executors" to facilitators. Their role includes:
- Environment Setup: Ensuring the UAT environment has representative data (scrubbed of PII for NZ compliance).
- Support: Helping business users log bugs, providing clarification on "is this a bug or a feature?", and triaging issues.
- Evidence Collection: Ensuring users capture enough detail (screenshots/logs) to satisfy an audit trail.
These levels are typically performed in sequence, though in Agile teams they often overlap. The key is that each level has a distinct purpose and a distinct perspective.
3 The Analogy
Imagine a car factory in Christchurch building a new electric vehicle.
Unit testing is like testing the engine on a bench rig. You check that the motor spins at the right RPM, that the cooling pump moves fluid, and that the battery cell holds charge. Each part is tested alone, disconnected from the car.
Integration testing is fitting the engine into the chassis and connecting it to the transmission, brakes, and electronics. You now care about whether the engine mount bolts line up, whether the CAN bus messages reach the dashboard, and whether the regenerative braking talks to the battery management system.
System testing is taking the complete car to the proving ground. You test acceleration, range, handling, crash safety, and whether the touchscreen works in the rain. The car is whole, and you are verifying it against the design specification.
Acceptance testing is the customer test drive. A family from Nelson takes it for a weekend trip to Hanmer Springs. Do the child seats fit? Is the boot big enough for camping gear? Does the charger work at the holiday park? This is about real-world fitness for purpose, not engineering specs.
Each level finds different problems. The bench rig will not tell you that the exhaust rattles against the chassis. The proving ground will not tell you that the cup holders are too small for a KeepCup. You need all four.
4 Watch Me Do It
Let’s walk through a Kiwi banking app — say, a mobile app for a credit union with branches across the North Island. Here is what testing looks like at each level.
| Level | Example Tests | What Could Go Wrong |
|---|---|---|
| Unit | The “calculate interest” function is tested with positive balance, zero balance, negative balance, and maximum decimal precision. | If interest is calculated using floating-point arithmetic without rounding to cents, micro-errors compound over thousands of transactions. |
| Integration | The interest calculation module is connected to the transaction history API. Test that a deposit on Monday correctly affects Tuesday’s interest, including public holidays. | The API might return dates in UTC while the interest module expects NZST. A deposit at 11 p.m. on Sunday (NZST) could be recorded as Monday UTC, skipping a day of interest. |
| System | The complete app is tested end-to-end: log in, view accounts, transfer between savings and cheque, set up an automatic payment to a NZ bank account, and receive a confirmation email. | The email might render incorrectly in Outlook. The transfer might fail if the destination bank is in a different clearing batch. Biometric login might not fall back to PIN on older iPhones. |
| Acceptance | A branch manager in Palmerston North uses the app for a week of real banking: paying suppliers, checking term deposit rates, and exporting GST records to Xero. | The export format might not match Xero’s expectations. The term deposit screen might confuse customers who are used to the old layout. The app might drain battery on a three-year-old Samsung. |
5 When / When-not
| When Each Level Is Appropriate | When Skipping a Level Is Dangerous |
|---|---|
| Unit: Always. Every code change should have unit tests. They are fast, cheap, and give developers immediate feedback. | Skipping unit tests because “it is just a small change” is dangerous. Small changes break things all the time. A one-line fix to a GST rounding function can bankrupt a report. |
| Integration: Whenever two or more components, services, or systems connect. APIs, databases, third-party services, and message queues all need integration testing. | Skipping integration testing because “the mocks passed” is how the telco lookup bug happened. Mocks lie. Real services have latency, timeouts, and data formats that mocks do not replicate. |
| System: Before any release candidate leaves the team. System testing verifies the whole product meets its specification. | Skipping system testing because “we tested each story” is risky. Stories are tested in isolation. System testing finds the gaps between stories. |
| Acceptance: Before go-live, and after significant changes. Acceptance testing answers the question: “Can real users do real work?” | Skipping acceptance testing because “QA signed off” ignores the fact that testers are not users. A tester knows how the system is supposed to work. A user just wants to get their job done. |
Before you design a test level strategy, ask:
- Does your organisation actually have multi-level testing, or do you jump from unit to production?
- Are your teams clear on who owns each level, or is it ambiguous?
- Which gaps in your testing have caused the most production bugs?
6 Common Mistakes
✗ Confusing integration testing with system testing
Correction: Integration testing verifies that components connect and communicate. System testing verifies that the whole product meets requirements. If you are checking whether the payment API returns the right HTTP status, that is integration. If you are checking whether a customer can complete a purchase end-to-end, that is system. Keep the boundaries clear in test plans and status reports.
✗ Thinking UAT is just “more testing”
Correction: User Acceptance Testing (UAT) is not a longer regression suite. It is a validation of business value. UAT should be run by users, in user environments, with user data. If your testers are running UAT scripts in a staging environment with synthetic data, you are doing system testing with a misleading label.
✗ Skipping unit tests because “we have good testers”
Correction: Testers cannot unit test. They do not have access to the code internals, and they should not need to. Unit tests are a developer responsibility. Expecting testers to find unit-level bugs in system testing is wasteful: the feedback loop is hours or days instead of seconds, and reproducing the issue is harder.
When test levels fail
Skipping an entire test level is common under deadline pressure. The cost is predictable: bugs that live at the skipped level escape to the next one, where they are more expensive to debug and fix. Skipping unit→integration finds API bugs late. Skipping integration→system finds real-world data failures late. Skipping system→acceptance finds workflow bugs in production.
7 Now You Try
For each scenario below, decide whether it describes unit, integration, system, or acceptance testing. Click to reveal.
Scenario A: A developer writes a test that calls the “validate NZ driver licence number” function with a valid licence, an expired licence, and a fake number. No database, no UI, just the function.
Unit testing. A single function is tested in isolation with varied inputs. No dependencies, no external systems.
Scenario B: The licence validation service is connected to the NZ Transport Agency API. A test sends a real lookup request and checks that the response is parsed correctly, handling both “valid” and “not found” responses.
Integration testing. Two systems are talking to each other. The focus is on the interface, not the end-user workflow.
Scenario C: A car rental company in Queenstown has staff use the new booking app for a week before go-live, processing real customer enquiries and checking that the printed contract matches what the customer agreed to.
Acceptance testing. Real users, real environment, real business process. The question is not “does it work?” but “can we run our business with it?”
Scenario D: The complete rental app is tested on iOS, Android, and desktop Safari. Tests cover search, booking, payment, email confirmation, and calendar sync across all platforms.
System testing. The whole product is tested against requirements, across platforms. Independent testers verify functional and non-functional behaviour.
8 Self-Check
Q1: A bug exists in the way two microservices exchange JSON messages. Which test level should have caught it?
Integration testing. Unit tests would test each microservice in isolation, likely using mocks for the other service. System testing might catch it, but only if the error propagates to an observable user symptom. Integration testing is specifically designed to find interface and communication failures between components.
Q2: Why is acceptance testing typically done by users rather than professional testers?
Professional testers know how the system is designed to work and may unconsciously avoid edge cases or workarounds. Users approach the system with their real goals, habits, and expectations. A tester might never think to use the browser back button during a payment flow; a user will. Acceptance testing needs that naive perspective.
Q3: In an Agile team, do test levels still apply if we are not doing a formal “system test” phase?
Yes. The levels are conceptual, not phases. In Agile, a team might run unit tests on every commit, integration tests in a CI pipeline after each merge, and system-level exploratory testing each sprint. Acceptance might happen as part of sprint review with stakeholders. The levels still exist; they just overlap and repeat more frequently.
9 Interview Prep — Junior Q&A
Kiwi employers expect junior testers to understand test levels clearly. Be ready to explain the differences.
Q. "What's the difference between unit testing and integration testing?"
Unit testing tests a single function or component in isolation. Integration testing tests how two or more components work together. In a payment system, unit testing checks "does the discount calculation work?" Integration testing checks "does the discount calculator talk correctly to the pricing engine and database?" Both are needed.
Q. "When would you skip a test level, and when would you never skip it?"
You should never skip all four levels. But in time-pressure, you might combine unit+integration into developer testing, then do proper system testing. Never skip integration testing if components communicate over APIs or databases—that's where real-world bugs hide. The telco lookup bug I mentioned happened because integration testing was skipped.
Q. "How is acceptance testing different from system testing?"
System testing checks if the software meets the specification. Acceptance testing checks if the software delivers business value to actual users. A system might pass system testing perfectly but fail acceptance testing if it is too slow, confusing, or doesn't match real workflows. System testing is done by testers; acceptance testing is best done by users or business analysts.