Learning Objectives
By the end of this lesson, you'll be able to:
- 🔩 Describe the four levels of software testing and what each checks
- 🏗️ Explain the testing pyramid and why it looks the way it does
- 👤 Know who owns each level (developers, QA, or business stakeholders)
- 🎯 Identify which level catches which type of bug
The Big Idea
Think of software like a machine made of bolts, subassemblies, and a final product.
You test the bolt alone first (unit test). Then you test it in the assembly (integration test). Then you test the whole machine running (system test). Finally, you hand it to the customer and say "does this do what you needed?" (acceptance test).
Each level catches different bugs. Skip a level and bugs slip through to the next — where they're harder and more expensive to find.
Level 1: Unit Testing
What it tests: A single function, method, or component — in complete isolation from everything else.
Example: Testing a function that calculates a discount percentage. The test calls the function directly with a price and discount rate and checks the returned value — no database, no UI, no API.
What it catches:
- Logic errors in a single function
- Edge cases at the code level (division by zero, null inputs)
- Regressions in specific calculations
Who does it: Developers. Unit tests are written by the person who wrote the code — they're part of the development process, not a separate QA phase.
Typical volume: Thousands. Unit tests are fast (milliseconds each), cheap to write, and the foundation of the testing pyramid.
What manual QA does here: Nothing — this is developer territory. But knowing unit tests exist helps you understand what shouldn't need to be tested manually.
Level 2: Integration Testing
What it tests: How two or more components work together — the connection points, data hand-offs, and interactions between units.
Example: Testing that the payment module correctly communicates with the order module. The discount is calculated, applied to the order, passed to the payment processor, and the order status updates in the database.
What it catches:
- Mismatches between how components expect to communicate (wrong data format, missing fields)
- Database query failures that work individually but fail in combination
- Third-party API integration issues
- Authentication/authorization broken between layers
Who does it: Developers and QA engineers (often automated). Manual QA may perform informal integration checks as part of system testing.
What it looks like for QA: API testing — sending requests directly to API endpoints and verifying the response structure, status codes, and side effects (like database changes).
Level 3: System Testing
What it tests: The complete, integrated system — all components working together as a whole, against the full requirements.
Example: Testing the entire checkout flow: browse → add to cart → apply coupon → enter payment → confirmation email → inventory update. All components involved.
What it catches:
- End-to-end flow breakdowns
- Missing or incorrect behavior against requirements
- Cross-feature interference (a bug in feature A that breaks feature B)
- Performance, security, and non-functional issues (at this level, you see them in context)
Who does it: QA teams. This is the primary level where manual QA testers work.
Key characteristics:
- Tests the system as users experience it
- Includes functional, non-functional, UI/UX testing
- Most test cases written here come from requirements and user stories
- Closest to "how the user actually uses the product"
Level 4: Acceptance Testing
What it tests: Whether the system meets the business requirements — does it do what the stakeholders agreed it should do?
Example: The product owner, business analysts, or real end users run through defined scenarios and verify the system solves the problem it was built to solve.
What it catches:
- Misunderstandings between what was built and what was actually needed
- Business rule violations that slipped through earlier levels
- User workflow problems that only surface with real usage patterns
- "Works correctly but solves the wrong problem" scenarios
Types of acceptance testing:
- UAT (User Acceptance Testing): Actual business users test the system
- Alpha testing: Internal company users (controlled environment)
- Beta testing: External real users (covered in the next lesson)
Who does it: Business stakeholders, product owners, end users. QA may facilitate but doesn't own acceptance testing.
The Testing Pyramid
/\
/AT\ ← Acceptance Testing (few, high-value, slow)
/----\
/ ST \ ← System Testing (many, manual + automated)
/--------\
/ IT \ ← Integration Testing (automated, API-level)
/------------\
/ UT \ ← Unit Testing (thousands, fast, developer-owned)
/________________\
Why this shape?
- More unit tests than anything else — they're fast, cheap, and catch problems early
- Fewer acceptance tests — they're slow, expensive, and need business involvement
- Bugs caught lower in the pyramid cost less — fixing a unit test failure takes minutes; fixing an acceptance test failure takes days
The anti-pattern: the ice cream cone. Heavy manual testing at the top, no unit or integration tests at the bottom. Results in slow feedback, expensive bug discovery, and fragile systems.
Who Owns Each Level
| Level | Primary Owner | QA Role |
|---|---|---|
| Unit | Developer | Awareness; don't re-test what's already unit-tested |
| Integration | Dev + QA | API testing, data flow verification |
| System | QA | Primary owner — this is where manual QA lives |
| Acceptance | Business / Product | Facilitator, script writer, issue logger |
Pro Tips
💡 Don't manually test what unit tests already cover. If a developer has 40 unit tests for a calculation function, you don't need to test every combination manually. Focus your system-level testing on the flow, not the math.
💡 System test failures that can't be reproduced in unit tests are integration bugs. If "it works in unit tests but breaks in the app," the problem is in how pieces connect — not in the pieces themselves.
💡 Acceptance testing is about the right problem, not just the right code. A perfectly functional feature that nobody asked for is still a failure. Always tie acceptance criteria back to the original business goal.
Summary
- 🔩 Unit = one function, one test, developer-owned, fast and numerous
- 🔗 Integration = components talking to each other, catches connection bugs
- 🖥️ System = complete working system — where manual QA primarily operates
- ✅ Acceptance = does it solve the real business problem? — business-owned
- 🏗️ Testing pyramid: more tests at the bottom (unit) than the top (acceptance)
- 🎯 QA's home level is system testing — everything built, nothing held back
Up next: Lesson 4.3 — Alpha & Beta Testing: when real users join the testing process. 👥