Search for "types of software testing" and you mostly find a flat list that mixes test levels, quality characteristics, and approaches into one muddle. That helps nobody plan. Poor software quality cost US organizations roughly $2.41 trillion in 2022 (CISQ, 2022), much of it from defects nobody caught in time. This guide sorts the field cleanly along the three axes of the ISTQB framework: when you test, what you test, and how you test. You'll get a practical level-by-type matrix, current market data, and concrete pointers for regulated industries such as banking.

In brief: Test types split into three axes: test levels (when), quality characteristics (what), and approaches (how). This split stops the common confusion of integration tests with smoke tests. According to the World Quality Report, 68% of organizations now use or plan to use GenAI in quality engineering (WQR 2024-25, 2024).

Figure 1: The three ISTQB axes – when, what, and how you test.

Why distinguish different types of software testing at all?

Figure 4: What poor software quality costs – $2.41 trillion.

Distinguishing test types cleanly isn't academic vanity; it cuts cost. Poor software quality caused around $2.41 trillion in damage in the US in 2022, including $1.56 trillion from operational failures (CISQ, 2022). Use test types deliberately, and you catch defects earlier and cheaper.

The trouble with nearly every online list: it throws together terms that live on entirely different planes. A component test describes *when* you test. A security test describes *what* you check. A smoke test describes *how* you proceed. In practice these three questions blur together constantly, and that blur is exactly where gaps in a test concept appear.

So the ISTQB framework separates three axes. It sounds pedantic at first. But the moment you design a test strategy for a real project, you need that separation to avoid missing quality characteristics. The sections below walk through each axis on its own.

Which three axes organize the types of software testing?

Under ISTQB, software testing splits into three independent axes: test levels, test types in the narrow sense, and approaches. This division follows ISO/IEC/IEEE 29119 (process) and ISO/IEC 25010 (quality model) and underpins the ISTQB Certified Tester Foundation Level v4.0.

The first axis, the test levels, answers when in the development flow you test. The second axis, the test types in the narrow sense, asks which quality characteristic per ISO/IEC 25010 you check. The third axis, the approaches, describes the activity or method you apply.

A concrete example makes this tangible. A regression test at system level that checks functional behavior combines all three axes: system test (level), functional test (type), and regression (approach). Only when you can name these coordinates is your test case described unambiguously.

The three axes at a glance

• Axis A — test levels (when): component/unit test, integration test, system test, acceptance test.

• Axis B — test types (what): functional, non-functional, performance, usability, security, and structural testing.

• Axis C — approaches (how): smoke test, regression test, end-to-end test, exploratory testing, re-test, black-/white-box.

What are the four test levels (Axis A)?

Figure 2: The four test levels from component to acceptance test.

The four test levels order tests by their point in the development process: component test, integration test, system test, and acceptance test. They follow the logic of the V-model and check step by step, from the smallest unit up to the whole system from a user's view. Each level has its own owners, tools, and defect classes.

The component test (unit test) checks the smallest isolated unit, usually a function or class. Developers typically write it themselves, often test-driven. The integration test checks how several components interact across their interfaces; many defects hide precisely here, at the seams between modules.

The system test examines the fully integrated system against its specified requirements. The acceptance test, finally, validates from the customer's or user's perspective. It has several subtypes: user acceptance testing (UAT), operational acceptance, regulatory acceptance, and contractual acceptance. For banks especially, regulatory acceptance testing with audit-ready evidence is central.

Each level brings its own owners, tools, and typical defect patterns. The overview below makes tangible who checks what at which level, and which class of defect dominates there:

The pattern is clear: the higher the level, the costlier the fix. A defect missed at an interface often resurfaces in the system test as a hard-to-locate follow-on problem. That's exactly why deliberately spreading test depth across all four levels beats one late, sprawling test run just before release.

How do responsibilities shift?

With each level, the perspective moves from code toward business value. At the bottom, engineering tests technically; at the top, the business or compliance team checks against real requirements. In practice, teams most often underestimate the middle levels, integration and system.

What do test types in the narrow sense check (Axis B)?

Test types in the narrow sense check individual quality characteristics per ISO/IEC 25010, such as functionality, performance, or security. The most important split runs between functional and non-functional testing. Functional tests ask *whether* the software does the right thing; non-functional tests ask *how well* it does it.

The non-functional test types form several clearly bounded families. Performance, load, and stress testing measures response times and behavior under peak load. Usability testing checks operability from the user's view. Security testing hunts for vulnerabilities and attack surfaces.

On top of these come tests for reliability, compatibility, and portability, plus the structure-based white-box test, which examines internal code structure and coverage. These characteristics can't be deferred at will. Check security or performance only just before go-live, and you risk expensive rework, a recurring pattern across many projects.

Which approaches exist (Axis C)?

Approaches describe *how* you test, not when or what. They include the smoke test, regression test, end-to-end test, exploratory testing, and re-test. These methods apply across multiple levels and quality characteristics, so they form not a separate plane but a cross-cutting dimension.

The smoke test runs a fast functional pass to check whether a build is even stable enough for deeper testing, the smoke check before the real run. The regression test makes sure existing features still work correctly after changes. Both are often automated because they run frequently and unchanged.

The end-to-end test maps complete business processes across all systems and checks them from the user's view. Exploratory testing, by contrast, deliberately drops scripts: experienced testers probe the application and surface defects that rigid test cases miss. The re-test, finally, verifies that a fixed defect is actually resolved.

How do test levels and test types relate?

Figure 3: The level-by-type matrix as a planning checklist.

Test levels and test types aren't alternatives but coordinates of the same plan: each level can hold several test types. This very combinatorics is what most online lists omit. The matrix below shows which test type usually makes sense at which level, the central planning tool for your test strategy.

Read the matrix as a checklist: every cell marked "typical" belongs in a complete test concept. Notably, non-functional characteristics like performance and usability only reach full weight at the system and acceptance levels. Factor them in earlier and you avoid late surprises, though you can rarely pull them all the way forward.

The approaches from Axis C lie across this matrix. A regression test, for instance, can run at any level and for any test type. That's why it sits in no fixed column, but is a method you apply to whichever cell fits.

How is AI changing the types of software testing?

Artificial intelligence mainly changes the *how* of test execution, not the taxonomy itself. 72% of organizations report that GenAI has accelerated their test automation (WQR 2024-25, 2024). The test types stay the same; AI just lowers the effort to carry them out.

AI's biggest lever sits with repeatable approaches like regression and smoke tests. Self-healing locators detect changed UI elements automatically and cut the notorious maintenance burden of brittle test scripts. Visual recorders let non-technical specialists record functional end-to-end tests too. These mechanisms work across web, mobile, API, and desktop.

Concretely, AI maps onto individual test types like this today:

• Regression test: self-healing locators keep large suites running despite UI changes and cut maintenance load.

• Smoke test: AI generates lean build-verification checks that fit as a fast gate in the pipeline.

• Functional and end-to-end test: visual recorders capture real user flows without scripting.

• Structural test: models suggest test cases for uncovered code paths and raise coverage.

Not every test type benefits equally. Exploratory testing, for one, runs on human curiosity and resists meaningful automation; AI offers at most a hint of where a closer look pays off.

Despite the hype, a gap remains. 57% of respondents have no comprehensive test automation strategy, and 64% cite legacy systems as a barrier (WQR 2024-25, 2024). Tools alone don't fix that. How to map AI sensibly onto each test type is something our guide to AI-driven test automation explores in depth.

What should you make of the "100x" myth?

Little. The often-quoted claim that a defect costs a hundred times more in production is an unverifiable zombie number with no primary source. What is solid, by contrast, is the CISQ finding of $2.41 trillion in damage (CISQ, 2022). Argue with sources, not rules of thumb.

Does the effort pay off economically?

Structured testing with clear automation pays off measurably, even though figures swing by context. In a study Forrester ran for Tricentis, one SAP customer reached a 403% ROI and 83% faster releases (Tricentis/Forrester, 2026). That's a single case, not an industry average, but a telling one.

The overall test automation market grows accordingly. Analysts estimate the volume rising from $25.43 billion (2022) to $92.45 billion by 2030, a compound annual growth rate of around 17.3% (Grand View Research, 2023). Individual analyst estimates vary, but the direction is clear.

The data foundation is professionalizing too. The use of synthetic test data rose from 14% (2024) to 25% (2025) (WQR 2025-26, 2025). For regulated industries that matters: synthetic data sidesteps privacy hurdles without lowering test coverage.

How do regulated industries choose the right test types?

Banks and regulated firms must align test types with evidence obligations, not just technical risk. Regulatory acceptance testing produces audit-ready evidence that withstands supervisory requirements such as DORA or BaFin rules. Here it isn't enough *that* you tested; it must be documented without gaps.

This requirement shifts the weight of the axes. Where startups often lean on fast smoke and regression tests, banks must back the acceptance level with auditable artifacts. Security and reliability tests move forward, because outages and data leaks carry regulatory penalties.

A practical consequence: test automation must deliver tamper-evident logs. Across DACH customer projects, automated, versioned test evidence noticeably shortens reconciliation with auditors. The technical foundation for that is covered in our piece on the integration test and its interface evidence.

FAQ

What is the difference between a test level and a test type?

A test level describes the point in the development process (component, integration, system, acceptance); a test type describes the quality characteristic checked (functional, performance, security). They're independent axes: one level can carry several test types. ISTQB separates them deliberately to prevent gaps in the test concept.

How many types of software testing are there?

There's no fixed number, because test types follow the quality characteristics of ISO/IEC 25010. Practically, you distinguish around eight main families: functional, performance, usability, security, reliability, compatibility, portability, and structural. On top come approaches like smoke, regression, and end-to-end tests as their own axis.

Which types of software testing should you automate?

Repeatable, stable approaches such as regression and smoke tests suit automation best, because they run often and unchanged. 72% of organizations report that GenAI has accelerated their test automation (WQR 2024-25, 2024). Exploratory testing, by contrast, stays human.

Are smoke tests and sanity tests the same?

No, they're related but distinct approaches. The smoke test checks broadly and shallowly whether a build runs at all. The sanity test checks narrowly and specifically whether a particular fix works. Both are fast filters before deeper test runs, but with different focus.

Which test types do banks strictly require?

Banks prioritize acceptance, security, and reliability tests with audit-ready documentation. Regulatory frameworks such as DORA and BaFin rules demand auditable evidence across the full sequence of test levels. Functional tests alone don't suffice; the decisive factor is gap-free, tamper-evident logging of every test run.

Conclusion

Test types become a steering instrument only once you separate them cleanly along three axes: test levels for the *when*, test types for the *quality characteristic*, and approaches for the *method*. The level-by-type matrix turns that theory into a tangible checklist so you miss no relevant check. Given $2.41 trillion in damage from poor software quality (CISQ, 2022), this discipline isn't optional. AI today noticeably lowers the effort for repeatable test types, but replaces neither strategy nor expertise. If you want to automate your test strategy across web, mobile, API, and desktop, talk to the Autemos team about your specific use case.