A map of the types of testing
A friendly orientation map of the whole testing landscape: functional vs non-functional, the four levels, black/white/grey box, and the quick checks (smoke, sanity, regression, re-test).
If you search "types of software testing", you'll drown in a chart with fifty boxes and arrows everywhere. It's overwhelming, and honestly, most of that chart won't matter to you for months. So instead of memorising fifty terms, let's draw a simple map. By the end you'll know the main neighbourhoods of testing and how they relate, and the deeper lessons later will fill in the streets.
This is an orientation, not a deep dive. Each idea below gets its own full lesson later. For now, the goal is a mental map you can hang everything else on.
Split one: functional vs non-functional
The first and biggest split asks a simple question: are you testing what the software does, or how well it does it?
Functional testing
- Tests WHAT the software does.
- Checks features against the requirements.
- "When I click Pay, does the payment go through?"
- Answer is usually a clear pass or fail.
- Examples: login works, search returns results, the form saves.
Non-functional testing
- Tests HOW WELL the software does it.
- Checks qualities like speed, safety, and ease of use.
- "When 10,000 people click Pay at once, does it stay fast?"
- Answer is often a measurement against a target.
- Examples: performance, security, accessibility, usability.
A handy way to remember it: functional testing asks "does it work?", and non-functional testing asks "is it good?". A button can work perfectly (functional pass) and still take eight seconds to respond (non-functional fail).
Split two: the four levels of testing
Testing also happens at different levels, zooming out from the tiniest piece of code to the whole product in a customer's hands. Picture building a car: you test each bolt, then the assembled engine, then the finished car on a track, and finally let the buyer take a test drive.
| Level | What's being tested | Usually done by | Car analogy |
|---|---|---|---|
| Unit | One small piece of code on its own | Developers | Testing a single bolt or spark plug |
| Integration | Several pieces working together | Developers / testers | Checking the assembled engine |
| System | The whole application end to end | Testers | Driving the finished car on a track |
| Acceptance | Does it meet the user's real needs? | Users / business / testers | The buyer's test drive |
The levels go from small and technical (unit) to broad and human (acceptance). Bugs caught at the unit level are the cheapest of all, which is exactly why developers write little automated unit tests as they code. It's shift-left in action.
Split three: black box vs white box vs grey box
This split is about how much of the inner workings you can see while testing. The "box" is the software, and the colour describes how transparent it is to you.
| Approach | What you can see | How you test | Everyday picture |
|---|---|---|---|
| Black box | Nothing inside; only inputs and outputs | Use the software like a real user, no peeking at code | Driving a car without opening the hood |
| White box | Everything; the actual code inside | Design tests based on the code's internal paths | A mechanic testing with the hood wide open |
| Grey box | A bit of both; some inner knowledge | Test like a user, but use inside knowledge to test smarter | A driver who also understands engines |
Most hands-on QA work, especially when you're starting out, is black box: you use the product the way a customer would and judge it by its behaviour, not its code. White box is more of a developer's tool. Grey box is the sensible middle most experienced testers drift toward.
The quick four: smoke, sanity, regression, re-test
Finally, four short, practical terms you'll hear every single week on a real team. They're easy to mix up, so here they are plainly.
- Smoke testing: a quick, shallow check that the most important things work at all, before deeper testing begins. "Does the app even open and let me log in?" If smoke fails, don't bother going further yet.
- Sanity testing: a quick, narrow check that one specific fix or feature behaves, without testing everything. "They fixed the search bug, let me just confirm search works now."
- Re-testing: running the exact test that found a bug, after it's marked fixed, to confirm it really is fixed. Same steps, same data, checking that specific defect.
- Regression testing: re-running a broader set of tests to make sure a new change didn't break something that used to work. The word regression means "slipping backward", and it's one of the most important ideas in all of testing.
Re-testing vs regression trips up nearly every beginner. Re-testing confirms the bug you reported is gone. Regression confirms the fix didn't accidentally break something else. You almost always do both, in that order.
That's the whole map: functional vs non-functional, the four levels, the three boxes, and the quick four. You don't need to master any of them yet. You just need to recognise the neighbourhoods so you don't get lost. As you keep learning, these terms will turn from vocabulary into instinct.
- Functional testing asks "does it work?"; non-functional testing asks "is it good?" (speed, security, usability).
- The four levels zoom out from small to broad: unit, integration, system, acceptance.
- Black box tests behaviour with no view of the code; white box tests with full code knowledge; grey box mixes the two.
- Smoke = does it basically work; sanity = is this one fix okay; re-test = is the reported bug gone; regression = did we break anything else.