Testing, Validation & Quality Assurance

Test Levels

18 min Lesson 2 of 10

Test Levels

Not all defects look the same, and not all tests catch them at the same stage. A bug in a single calculation function behaves very differently from a bug that only surfaces when three integrated subsystems talk to each other — or from a mismatch between what users expected and what developers built. Test levels are the structured answer to this reality: each level targets a specific scope of the system, uses specific techniques, and is owned by a specific team. Working from the smallest unit upward, the four universally recognised levels are Unit, Integration, System, and Acceptance testing.

Understanding where each level sits — and who is responsible for it — is one of the most practically useful things a systems analyst can know. When a stakeholder asks "how do we know the system is correct?" the analyst must be able to give a structured answer that spans all four levels.

The V-Model: Analysis and Testing as Mirror Images

The classic way to visualise test levels is the V-Model. The left arm descends through analysis and design phases; the right arm ascends through the corresponding test phases. Each test level directly validates the phase on its mirror side: unit tests validate detailed design, integration tests validate architectural design, system tests validate the system requirements specification (SRS), and acceptance tests validate the original business requirements.

The V-Model: each test level on the right arm directly validates the analysis or design phase mirrored on the left arm.

Level 1 — Unit Testing

Scope: A single function, method, class, or module — the smallest independently testable piece of code.

Owner: The developer who wrote the code. Unit tests are written by developers, often before or alongside the production code (as in Test-Driven Development).

What it checks: Does this function return the correct result for valid inputs? Does it handle invalid inputs gracefully? Does it meet the logic specified in the detailed design?

Business example — online store: The pricing engine has a function applyDiscount(price, couponCode). A unit test checks: Does a 10%-off coupon produce the right discounted price? Does an expired coupon return the original price? Does a null coupon code throw a controlled error rather than crashing? These tests run in milliseconds, require no database, and give the developer immediate feedback.

Analyst insight: Unit tests are most valuable when business rules are complex — tiered pricing, tax calculations, eligibility checks. The analyst who writes clear, precise requirement statements makes it far easier for developers to write meaningful unit tests. Vague requirements like "apply the discount correctly" cannot be unit-tested; precise requirements like "apply a 10% reduction when the coupon is active and the cart total exceeds $50" can be.

Level 2 — Integration Testing

Scope: Two or more components working together — a module calling a database, a service consuming an API, a payment gateway interacting with an order system.

Owner: Typically a mix of senior developers and QA engineers. Integration testing spans team boundaries, so coordination matters.

What it checks: Do the interfaces between components match? Does data flow correctly across module boundaries? Are shared resources (databases, queues, external APIs) handled correctly under combined load?

Business example — online store: After individual unit tests pass, the integration test verifies that the OrderService correctly writes a confirmed order to the database AND simultaneously triggers a message to the NotificationService (which sends a confirmation email), AND decrements the correct product quantity in the inventory module. Each module worked alone; the integration test checks that they work together without data loss or race conditions.

A common integration failure is the interface mismatch: the payment service expects an amount in cents (integer) but the order service sends a decimal in dollars. Both pass unit tests in isolation; only an integration test catches the discrepancy.

Common mistake: Skipping integration testing because unit tests all passed. Unit tests run each component in isolation with mocked dependencies. They cannot detect problems that only arise when real systems interact — network timeouts, database transaction conflicts, or mismatched data formats across API boundaries.

Level 3 — System Testing

Scope: The entire integrated system, tested as a complete product against the System Requirements Specification (SRS).

Owner: A dedicated QA or test team, independent of the development team. Independence matters here — the same developer who made an assumption about a requirement will make the same assumption when testing it.

What it checks: Does the complete system fulfil every functional requirement? Does it perform within acceptable limits (performance, security, reliability)? Does it behave correctly across all supported platforms and browsers?

Business example — logistics firm: The dispatch system's SRS specifies "drivers must be able to update delivery status from a mobile device within 3 seconds even on a 3G connection." System testing deploys the complete application to a staging environment, connects real GPS devices, simulates 200 concurrent drivers updating status, and measures response time. Unit and integration tests cannot answer this question — only a full-system test can.

System testing also covers negative scenarios: what happens if the GPS signal drops mid-update? What if a driver tries to mark a parcel as delivered before it is collected? These edge cases are derived directly from the SRS requirements and from the analyst's knowledge of real-world business processes.

Level 4 — Acceptance Testing (UAT)

Scope: The system from the perspective of the end-user and the business, validated against the original business requirements and real-world use cases.

Owner: The business — actual end-users, product owners, and the systems analyst. The analyst's role here is pivotal: they facilitated the requirements gathering and now facilitate the validation that those requirements have been met.

What it checks: Does the system do what the business actually needs? Is it usable by real people in real workflows? Does it comply with regulatory or contractual obligations? Is the business ready to sign off and go live?

Business example — logistics firm: After the QA team signs off on system testing, real dispatch coordinators and warehouse managers run the system using their actual daily tasks — booking collections, dispatching drivers, updating manifests, generating end-of-day reports. They are not following a script of technical test cases; they are doing their real jobs and reporting any gap between what they expected and what they experience. A system that passes all QA tests can still fail UAT if the interface is too slow for a warehouse worker managing 400 parcels per shift.

The analyst's UAT role: The systems analyst typically designs the UAT test scenarios (derived from use cases and business requirements), recruits and trains the user testers, mediates between users and developers when defects are found, and ultimately signs the UAT completion certificate that authorises go-live. This is why analysts must remain engaged through implementation, not just the analysis phase.

A Side-by-Side Summary

The four test levels compared by scope, ownership, and the artefact each level validates.

Why Ownership Matters to the Analyst

Each test level has a natural owner, but the analyst is responsible for ensuring that all four levels happen and that they are traceable back to the original requirements. The practical implication:

When creating the Requirements Traceability Matrix (RTM) (covered in lesson 6), each requirement should trace forward to at least one system-level test case and one acceptance test scenario.
During project planning, the analyst must confirm that the team has allocated time and budget for all four levels — projects that budget for unit testing but skip formal system testing often discover integration and SRS compliance gaps only after go-live.
When a defect is found, the analyst should ask "at which level should this have been caught?" A production bug that should have been caught in unit testing suggests a gap in the development team's practices. A defect caught only at UAT that stems from a misunderstood requirement points to a gap in the analysis process.

Key takeaway: The four test levels are not redundant — they catch different categories of defect. Unit tests catch logic errors in isolation. Integration tests catch interface and data-flow defects. System tests catch end-to-end functional and non-functional failures. Acceptance tests catch the gap between what was built and what the business actually needed. A rigorous QA strategy covers all four, in sequence, with clear ownership at each level.