Test levels and types: unit to acceptance, functional to non-functional

"Testing" is not one activity — it happens at different levels (from a single function up to the whole system) and in different types (checking behaviour, or speed, or security). A QA needs this vocabulary to say precisely what they are doing and to spot the gaps ("we have no load testing", "nobody tested the integration between the app and the payment provider"). This lesson maps the levels and types, so you can place any testing activity and see what is missing.

Test levels: how much of the system is under test

Testing happens at levels, from small to large, each catching different problems:

Unit testing — a single function or class in isolation. Fast, precise, and usually written by developers (every developer course ends with this). A QA rarely writes unit tests but should know they exist and form the base of the pyramid (the automation module).
Integration testing — do two or more parts work together? The app talking to the API, the API talking to the database, the API talking to the payment provider. Many bugs live between components that each work alone — a mismatch in what one sends and the other expects.
System testing — the whole application, end to end, as a user would use it: open the app, log in, make a top-up, see the balance update. This is much of a QA's focus — testing the assembled product, not the pieces.
Acceptance testing — does it meet the user's / business's need well enough to accept? Often framed as "user acceptance testing" (UAT), sometimes done with or by the customer or product owner.

The levels form a progression from "does this piece work?" to "does the whole thing meet the need?". A QA works mostly at system and acceptance levels (the whole product as the user meets it), while developers cover unit and much integration — but knowing all four lets you ask "which level is this bug at, and which level is under-tested?".

Functional versus non-functional testing

Cutting across the levels is a different distinction — what aspect you are testing:

Functional testing — does it do the right thing? Given this input, does it produce the correct output/behaviour? "When I top up ₹100, does my balance go up by ₹100?" Most testing is functional.
Non-functional testing — does it do it well enough, along dimensions other than correctness? These are the "-ilities", and they are where products often fail under real conditions:
- Performance / load — is it fast enough? Does it hold up when 10,000 agents use it at 9am?
- Security — can it be attacked, can one user see another's data (the API/security overlap)?
- Usability — can a real user actually complete the task without confusion?
- Compatibility — does it work across devices, OS versions, browsers (huge for mobile)?
- Reliability / resilience — does it survive a dropped network, a slow server, a retry?

A common failure is testing only the functional side — "it works when I try it" — and shipping something that is correct but unusably slow, or correct but insecure, or correct on a new iPhone and broken on a three-year-old Android. For the mobile-money apps this course targets, the non-functional aspects — compatibility (devices), reliability (connectivity), performance (load), security (money) — are often where the real risk lives.

Test activities: smoke, sanity, regression

Beyond levels and types, some named activities describe when and why you run a set of tests:

Smoke testing — a quick, shallow check that the build is not fundamentally broken before you invest in deeper testing. "Does the app launch, can I log in, does the home screen load?" If smoke fails, do not bother with the rest — send it back.
Sanity testing — a narrow, focused check that a specific fix or feature works, without full regression. "They fixed the top-up bug — does top-up now work?"
Regression testing — re-running tests to confirm that a change did not break something that used to work. The bug you fixed is not the only risk; the fix might break something else. Regression is a huge part of a QA's ongoing work (its own lesson), and the prime candidate for automation.

These are not levels or types but strategies for when to test what: smoke to fail fast, sanity to check a specific thing, regression to guard against breaking the old while adding the new.

Putting the map to use

The value of this vocabulary is coverage thinking — seeing what is tested and what is not. For any product, you can lay a grid over it:

Levels — are the pieces tested (unit/integration, mostly developers), the whole system tested (QA), and does someone confirm it meets the need (acceptance)?
Types — is it tested for correctness (functional) and for performance, security, compatibility and reliability (non-functional)?
Activities — is there a smoke check to fail fast, and a regression suite so old features stay working?

Gaps in that grid are where bugs escape. A team with great unit tests but no integration testing ships bugs between components. A team that tests functionally but never on an old phone ships a broken experience for half its users. A QA who can name the grid can say precisely "we are strong on functional system testing but have no load or compatibility testing" — which is exactly the kind of clear, actionable observation that makes a QA valuable. You do not have to do all of it yourself; you have to see the whole map and flag what is missing.

Check your work

Test levels. Unit (one function, devs), integration (parts working together — bugs live between components), system (the whole app end to end — much of QA), acceptance (meets the user/business need, UAT). QA works mostly at system and acceptance.

Functional vs non-functional. Functional = does it do the right thing (most testing); non-functional = does it do it well enough — performance/load, security, usability, compatibility, reliability. Mobile-money apps often fail on the non-functional side (devices, connectivity, load, money security).

Activities. Smoke (shallow "is the build broken?" — fail fast), sanity (narrow check of a specific fix/feature), regression (re-run to confirm a change did not break what worked — big, automatable).

Coverage thinking. Lay the levels × types × activities grid over a product to see what is tested and what is not; gaps are where bugs escape. A QA's value is seeing the whole map and flagging what is missing, not doing every part personally.

Practice

For an app you know, place three of its recent bugs at a test level (unit/integration/system/acceptance) and reason about which level should have caught each.
List, for a top-up feature, one functional test and one test each for performance, security, compatibility and reliability.
Write a 5-check smoke test for a mobile app (what must work or you send the build straight back).
Distinguish sanity from regression with an example of each after a bug fix.
Lay the levels × types grid over a product you use and name one cell that is probably under-tested.
Practise the QA sentence: "We are strong on ___ but have no ___ testing" for a real or imagined product.

Official documentation

ISTQB — Foundation syllabus (test levels and types) — The standard definitions of levels, types and activities.
Martin Fowler — TestPyramid — How the levels relate for automation.
ISTQB — Glossary — Precise definitions of smoke, sanity, regression and the rest.

Next: the QA mindset — thinking like a user and an adversary.