06 — The Test Types Landscape — Scope, Intent, and Timing

"Vocabulary to memorize for a certification" was my test-types model, and the names stayed noise until I found the structure underneath. The insight that revealed it: every test type is a slice across two axes — scope (how much of the system runs during the test) and intent (what question the test is asking) — and the dozens of names collapse onto that grid [1]. "Unit," "integration," "smoke," "regression," "stress," "UAT" aren't a flat list; they're positions on a 2D map, and once I saw the map, the names stopped feeling arbitrary.

The framing that landed is that each test type answers a different question. "Does this function work?" (unit), "do these modules talk to each other?" (integration), "is the build even alive?" (smoke), "did my change break something that worked?" (regression), "can it survive real traffic?" (load/performance), "will a real user accept this?" (UAT), "what haven't I thought of?" (exploratory). A test suite is a portfolio of bets across these questions, and the art is holding the right balance rather than over-investing in any one.

The two-axis map

Reading the grid: the bottom band ("does it work?") is where the developer spends most of their time — unit tests, integration tests, the daily verification that the code does what it says. The second band ("does it still work?") is regression's home — the gate that catches change-induced breakage. The third ("does it survive load?") is performance territory. The top ("will users accept it?") is the human-judgment band that automation can't touch. Every test I write sits somewhere on this map, and the question I ask of any suite is "which cells are empty?"

The bottom band: scope-based testing

The vertical axis the roadmap cares most about is scope — how much of the system runs during the test. This is the classic test pyramid, and the roadmap's nodes map onto it directly:

• Unit testing isolates the smallest possible piece — a function, a method — and verifies it in isolation [2]. Fast, numerous, narrow. This is where mocking lives (more on that below).
• Integration testing takes several modules that were built separately and tests them together — does the data flow between them correctly? [3] Slower, fewer, wider. Most real defects live at the seams between modules, which is why a suite of only unit tests gives false confidence.
• System / end-to-end testing runs the whole application, through the real browser or real API, simulating a user. Slowest, fewest, widest. These catch environment and wiring bugs that lower levels miss, but their slowness means you can't afford many.

The pyramid metaphor (many unit, fewer integration, fewest end-to-end) is a cost-speed tradeoff, not a moral hierarchy. Each scope catches a different class of defect, and a healthy suite has all three.

Functional versus non-functional

Cross-cutting the scope axis is the intent split between functional and non-functional testing [4][5]:

• Functional testing validates the system against functional requirements — does it do what it's specified to do? Login works, cart totals correctly, form submits. The output is checked against the spec.
• Non-functional testing validates the qualities — reliability, performance, security, usability. Not "does it work" but "how well does it work, under what conditions, for whom."

The roadmap makes a sharp point: non-functional parameters are never tested before functional testing [5]. There's no point load-testing a system that doesn't even work correctly at one user. Functional is the prerequisite; non-functional is the refinement.

The "does it still work?" band: build-confidence tests

This band holds three tests that all answer "should we even proceed?" but at different granularities:

• Smoke testing is the minimal set run on every build to confirm the build is stable enough to test further [6]. If smoke fails, you reject the build and don't waste time on deeper tests. It's the "is it alive?" check.
• Sanity testing is the narrower cousin — run after a minor code change to confirm the specific fix works and didn't introduce obvious new issues [7]. If sanity fails, the build is rejected before deeper regression.
• Regression testing re-executes existing test cases to confirm a recent change hasn't broken previously-working functionality [8]. This is what automation is best at, because the cases are known and stable and need to run on every change.

The distinction between smoke and sanity trips people up. Smoke is shallow-and-wide ("are the major paths alive?"); sanity is narrow-and-focused ("did this specific fix work?"). Both are gates that save the team from wasting a full test cycle on a broken build.

The "survive load?" band: performance testing

Performance testing is the umbrella, and the roadmap breaks it into sub-types that differ by what kind of load [9][10]:

• Load testing applies expected real-life load and measures behavior [11]. "Can it handle our normal peak?"
• Stress testing pushes beyond normal capacity to find the breaking point and observe how it fails [12]. "What happens when we exceed it?"
• Spike testing (a sub-type the roadmap's resources call out) applies sudden sharp surges. "Can it absorb a traffic spike?"
• Endurance / soak testing applies sustained load over a long period to surface memory leaks and degradation.

The shared output is metrics — response times (p95, p99), throughput, error rates — measured against service-level objectives. Performance testing without defined SLOs is just generating numbers.

The "will users accept it?" band: human judgment

The top band holds the tests automation can't replace:

• UAT (User Acceptance Testing) is performed by the actual end user or client, in the final phase, to accept or reject the software before production [13]. It's the validation step from my manual-testing notes — "are we building the right product?" — answered by the person who has to use it.
• Exploratory testing is simultaneous learning, test design, and test execution — the tester investigates the product, designing tests on the fly based on what they observe [14]. It's where the cases nobody wrote down get discovered. The roadmap's resources treat it as a first-class discipline with its own definitions and history, not as ad-hoc clicking.

These two are the unautomatable safety net. UAT catches the "built the wrong thing" failure; exploratory catches the "nobody thought to test this edge case" failure.

Mocking: the enabler of isolation

The roadmap's Mocking node belongs in the scope discussion because it's the technique that makes unit tests unit tests [15]. A mock is a simulated object that mimics a real dependency — a database, an API, another service — so the code under test can be exercised without the real dependency being available, slow, or stateful.

// the real dependency: a database that needs a network and persists state
// the mock: a fake that returns canned data, instantly, in-memory

// without mocking: unit test becomes an integration test by accident
// with mocking: the unit is tested in true isolation

The tradeoff is that mocks decouple the test from the real dependency's behavior — if the mock doesn't faithfully mimic the real thing, the test passes but the integration breaks. That's the seam integration tests exist to cover. Mock aggressively at the unit level; verify the real interactions at the integration level.

Security testing as a cross-cutting concern

The roadmap lists Security Testing as a node in this sprawl, and it's worth flagging that security is really its own vertical — it has its own dedicated post later in this series. For this map, security sits as a non-functional intent ("can it be attacked?") that applies at every scope: unit-level input validation, integration-level auth flows, system-level penetration testing. It's listed here to acknowledge it; the depth lives in the security post.

How I use this

The practical payoff is a portfolio question I ask of any test suite: which cells on the map are empty, and is that emptiness deliberate?

• A team with only unit tests has a false-confidence problem — the seams are untested.
• A team with only end-to-end tests has a speed problem — the suite takes an hour and nobody runs it locally.
• A team with no regression tests has a "we keep breaking the same thing" problem.
• A team with no exploratory or UAT has a "we built the wrong thing beautifully" problem — verification strong, validation absent.

The aim isn't to fill every cell; it's to know which cells you're consciously leaving empty and why. Test types aren't a checklist to complete — they're a portfolio to balance, and the balance shifts with the project's risk profile.

References

[1] Elprocus, "What are testing techniques: types, advantages & disadvantages," 2023. [Online]. Available: https://www.elprocus.com/what-are-testing-techniques-types-advantages-disadvantages/

[2] Guru99, "Unit testing tutorial," 2023. [Online]. Available: https://www.guru99.com/unit-testing-guide.html

[3] Guru99, "Integration testing tutorial," 2023. [Online]. Available: https://www.guru99.com/integration-testing.html

[4] BrowserStack, "What is non-functional testing," 2023. [Online]. Available: https://www.browserstack.com/guide/what-is-non-functional-testing

[5] BrowserStack, "Functional testing: a detailed guide," 2023. [Online]. Available: https://www.browserstack.com/guide/functional-testing

[6] Evaluat, "Smoke testing vs performance testing," 2024. [Online]. Available: https://www.evaluat.com/blog/smoke-testing-vs-performance-testing

[7] BrowserStack, "What is sanity testing?," 2023. [Online]. Available: https://www.browserstack.com/guide/sanity-testing

[8] Katalon, "What is regression testing? Definition, tools and examples," 2023. [Online]. Available: https://katalon.com/resources-center/blog/regression-testing

[9] Evaluat, "What is performance testing? A QA engineer's guide," 2024. [Online]. Available: https://www.evaluat.com/blog/what-is-performance-testing

[10] Evaluat, "Load vs stress vs performance testing," 2024. [Online]. Available: https://www.evaluat.com/blog/load-vs-stress-vs-performance-testing

[11] Evaluat, "Real-browser load testing, explained," 2024. [Online]. Available: https://www.evaluat.com/blog/real-browser-load-testing

[12] Evaluat, "Stress testing a website: find the breaking point," 2024. [Online]. Available: https://www.evaluat.com/blog/stress-testing-a-website

[13] Guru99, "What is User Acceptance Testing (UAT)?," 2023. [Online]. Available: https://www.guru99.com/user-acceptance-testing.html

[14] Satisfice, "Exploratory testing," 2024. [Online]. Available: https://www.satisfice.com/exploratory-testing

[15] Microsoft, "Mocking in unit tests — engineering playbook," 2024. [Online]. Available: https://microsoft.github.io/code-with-engineering-playbook/automated-testing/unit-testing/mocking/