Levels of Testing

Unit testing

What: the smallest testable piece of code, a “unit”: usually one function, method or class, tested in isolation. Anything it depends on (the database, the network, the clock) is replaced with a fake, so the test checks only that piece’s logic.

Who: developers, usually while writing the code. Unit tests are code themselves and run automatically on every change.

What it finds: wrong math, wrong conditions (”>” instead of ”>=”), unhandled empty or null values, off-by-one errorsOff-by-one errorA bug where a count or boundary is wrong by exactly one, like counting days instead of nights.Open in glossary →.

Here is what a unit test for a discount function might look like in JavaScript. You don’t need to write these, but it helps to recognize one:

test('SAVE10 takes 10% off the order', () => {
  expect(calculateDiscount(40.0, 'SAVE10')).toBe(4.0);
});

test('an expired code gives no discount', () => {
  expect(calculateDiscount(40.0, 'SUMMER23')).toBe(0);
});

Each test runs in a few milliseconds. A large app can have thousands, and they all run every time a developer pushes a change.

Integration testing

What: the connections between pieces. Two parts can each work perfectly on their own and still fail together: one sends a price as "4.00" (text), the other expects 4.0 (a number).

Who: developers and testers. QA engineers often test APIs directly with tools like postmanPostmanA popular tool for sending API requests and checking responses without using the app's UI.Open in glossary →; see API Testing with Postman.

There are two flavors worth knowing:

• Component integration testing: connections inside one system. The checkout screen and the cart module; the cart service and the coupon service, both built by your team.
• System integration testing: connections between your system and other systems. Your app and the payment provider, a maps service, an airline’s booking system, a bank.

A related, modern technique is the contract test: the two sides of an API agree on a “contract” (field names, types, status codes), and automated tests check that neither side breaks it. Contract tests are popular when many teams own many small services.

What it finds: wrong or missing data passed between parts, mismatched field names, wrong status codesHTTP status codeA three-digit number in every server response: 200 means OK, 404 not found, 500 server error.Open in glossary →, timeouts, the same order created twice, errors that one side doesn’t handle.

System testing

What: the complete, integrated product, tested end to end on an environment as close to the real one as possible. You test it the way users use it: through the screens, on real devices and browsers, with realistic data.

Who: mainly the test team: manual testers and automation engineers.

What it covers:

• Functional behavior: complete user journeys, business rules, error handling. Example: browse, add to cart, apply coupon, pay, get a receipt.
• Non-functional qualities: speed, security, usability, accessibility, compatibility across devices and browsers. See Types of Testing for these.

What it finds: broken end-to-end flows, problems that only appear when everything is connected, device- and browser-specific bugs, confusing UI, slow screens.

This is the level where you will spend most of your time as a manual tester, using techniques from How to Write Test Cases and doing exploratory testingExploratory testingLearning, designing and running tests at the same time, guided by curiosity and a goal.Open in glossary →.

Acceptance testing

What: the final question: is this what we actually need, and can we go live with it? System testing asks “does it work as specified?”; acceptance testing asks “is it fit for purpose?”. This is validationValidationChecking that we built the right product, one that really meets users' needs.Open in glossary → in action.

Who: the people the software is built for, often supported by testers. There are several kinds:

Some projects also have contractual acceptance (does it meet the contract?) and regulatory acceptance (does it meet laws, for example for banking or health apps).

What it finds: misunderstood business rules, workflows that are technically correct but awkward in real life, missing features, “this isn’t what we meant”.

One feature through all four levels

Let’s follow a single feature, “Apply a coupon at checkout” in a food delivery app, through every level. The rule: SAVE10 gives 10% off orders of €20 or more; one coupon per order.

Notice how each level found a bug the others would have missed (or found much later and more expensively).

The test pyramid

The test pyramid is a picture of how many tests a healthy team has at each level. The idea comes from automation: the lower the level, the faster, cheaper and more stable the test, so you want lots of them. The higher the level, the slower and more fragile the test, so you keep fewer, carefully chosen ones.

• Bottom (unit): thousands of tests, seconds to run them all.
• Middle (integration / API): hundreds of tests, minutes.
• Top (end-to-end system tests through the UI): dozens, can take an hour, and some become flakyFlaky testA test that sometimes passes and sometimes fails without any change to the code.Open in glossary →.
• Above it: manual exploratory testing and acceptance testing, which no automated layer replaces.

Why this matters to a manual tester

Most manual testers work at the system and acceptance levels. So why learn the others?

• You avoid duplicate work. If developers already have unit tests for every discount rule, you can spend less time on calculation combinations and more on the full journey.
• You write better bug reports. Saying “the API returns the right total but the app shows the old one” points the developer straight to the right place.
• You can test earlier. API endpoints often exist before the screens do; testing them in Postman is integration testing you can start days earlier.
• You speak the team’s language in planning, reviews and interviews.

Levels are not types

A level says how big the thing under test is. A type says what quality you are checking: functional, performance, security, usability, and so on. They combine: you can do performance testing at unit level (how fast is this function?) or at system level (how fast is the whole checkout?). regression testingRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → and smoke testingSmoke testingA quick check of the most important features to decide if a build is stable enough to test further.Open in glossary → also happen at several levels. See Types of Testing for the full map, and SDLC and STLC for how each level pairs with a design phase in the V-model.