A program can be checked at different scales: a single small piece, a group of pieces working together, the whole product at once, or the product through the eyes of a customer. These scales are called test levels. There are four of them, and they go from the smallest to the largest.

Understanding the levels matters so you know what you are responsible for. Some levels belong to developers; others belong to you. Let's look at each one using an online shop as an example.

Unit testing

The smallest level. A single small piece of the program is checked in isolation — for example, a function that calculates a discount. It is given different inputs and the result is checked: a 10% discount on 1000 is 100, and a discount on zero is zero.

Who does it: almost always developers, in code (these are automated tests). A manual tester does not usually write unit tests, but it is useful to know they exist: if they are good, fewer trivial calculation bugs will reach you.

Analogy: before assembling a car, each individual part is checked separately — a bolt, a spark plug, a brake disc.

Integration testing

One level up. The check is whether the pieces work together correctly. The cart works on its own and payment works on its own — but does the cart pass the right total to payment? The joints between parts are where things break most often: each piece is fine on its own, but together they are not.

Who does it: both developers (in code) and testers (manually, especially when the system talks to external services — a payment gateway, email). Joints between parts are the classic location for bugs; always keep that in mind.

Analogy: an engine is assembled from checked parts — and then you see whether it starts as a whole.

System testing

The whole product is checked as a user would see it. A tester walks through complete end-to-end scenarios: open the site, find a product, add it to the cart, place an order, pay, receive a confirmation email. Everything together, in its assembled state.

Who does it: this is the core work of a manual tester. Here you check not only that things "work" but also non-functional aspects — is it convenient, fast, secure.

Analogy: the assembled car is driven onto a track to see whether it moves, brakes, and whether the headlights work.

Acceptance testing (UAT)

The final check: does the product satisfy the customer or the user? The question here is not "are there bugs?" but "is this what was needed — can we release it?" This check is often run by the customer themselves or designated users, which is where the name UAT (User Acceptance Testing) comes from.

Who does it: the customer, the business, sometimes designated users. The tester helps: prepares scenarios, guides the session, records issues.

Analogy: the buyer sits in the car, takes it for a lap, and decides — yes or no.

The pyramid: what should there be more of

There is a well-known image — the test pyramid. At the base sit many fast, cheap unit tests; above them, fewer integration tests; at the very top, only a small number of slow system-level checks through the interface.

The point for a beginner: not everything needs to be checked at the top level through mouse clicks. If a discount calculation is reliably covered by unit tests, you do not need to go through every discount scenario by hand — it is enough to check that it is working in general. This helps you not spend effort where a cheaper check already exists.

Where this applies

Levels help you understand where to look for a bug and whose territory it is. If the cart total is wrong — that is probably unit-level calculation logic. If the cart is right but a different total reaches the payment step — that is a joint, an integration issue. If everything is fine separately but the end-to-end scenario falls apart — that is the system level. Knowing how to tell these apart, you describe bugs more precisely and find the responsible piece faster.

Where beginners stumble:

  • Checking everything through the interface, with clicks, even things it is cheaper to check with an API request or in the database.
  • Forgetting about joints. Each piece works, but together they do not; integration bugs are the most insidious ones.
  • Confusing system and acceptance. The first is "does it work without bugs", the second is "is this actually what the business needed".

What to learn next. Get familiar with types of testing — what exactly is being checked (functions, speed, usability, security) — and with black box and white box — how much you know about the internals when you go into a check.