Software testing involves many different types, and in day-to-day projects you’ll hear terms like “unit test,” “regression test,” and “E2E test” thrown around constantly. However, these terms are systematically organized, and internationally, the ISTQB (International Software Testing Qualifications Board) classification is the most widely referenced quasi-standard.

This article organizes commonly used test types based on the ISTQB framework, structured along three axes: test levels, test types, and test design techniques.

What Is Software Testing?

ISTQB defines software testing as:

An activity to evaluate software quality, discover defects, and reduce risk.

— ISTQB Glossary

Testing isn’t just about “finding bugs” — it’s a comprehensive activity to verify that software works as expected and to manage the risk of releases.

Test Levels — When and at What Granularity to Test

The most fundamental classification is test levels. This concept changes the granularity of what’s being tested along the development lifecycle, commonly known as the “V-model.”

ISTQB defines the following levels:

Unit Testing (Component Testing)

Verifies that the smallest units of a program (functions, methods) work correctly. The main focus is on logic correctness and boundary value verification.

Developers typically write these alongside implementation, and they’re the first tests executed in CI/CD pipelines.

Integration Testing

Verifies that when components within the same system are combined, there are no issues with interfaces or data exchange. Also known as “component integration testing.”

Examples include API-to-database connections and data flow between modules.

System Testing

Verifies that the system as a whole meets defined requirements (functional and performance). End-to-end scenario tests fall into this level.

System Integration Testing

While integration testing targets connections between components within a system, system integration testing verifies connections across system boundaries.

Examples include integration with third-party payment APIs and services developed by other teams.

Acceptance Testing (UAT)

Confirms that the system ultimately meets user business needs and is ready for deployment. This is a requirements validation from the user’s perspective and serves as the release gate.

Test Types — What Purpose Does the Test Serve?

Separate from test levels, there’s a classification by test purpose (test types). These perspectives can be applied at any test level.

Functional Testing

Tests that focus on “what the software can do,” verifying that it behaves according to specifications.

Test	Description
Functional Test	Verifying behavior matches specifications
Regression Test	Confirming changes haven’t broken existing functionality
Smoke Test	Basic verification immediately after a build or before release
Sanity Test	Lightweight check that specific changes work correctly
Exploratory Test	Experience-based technique where learning, design, and execution happen simultaneously
Confirmation Test (Re-test)	Verifying that a discovered bug has been correctly fixed

Regression testing is particularly important because it’s repeated with every change or feature addition, making it the top priority for automation.

Non-functional Testing

Tests that focus on “how the software performs.” Even if functionality works correctly, quality is insufficient if there are performance or security issues.

Test	Description
Performance Test	Response time and throughput verification
Load Test	Behavior under expected load
Stress Test	Behavior under peak/extreme load
Security Test	Vulnerability, authentication, and authorization verification
Usability Test	UX-focused ease-of-use verification
Accessibility Test	WCAG compliance and accessibility verification
Compatibility Test	Cross-browser, OS, and device behavior verification

Test Design Techniques — How to Design Tests

This axis addresses how test cases are created.

Black-box Testing

Tests software behavior through inputs and outputs without examining internal structure. Techniques include:

• Equivalence Partitioning: Grouping input values with the same behavior and testing with representative values
• Boundary Value Analysis: Focused testing on boundary conditions (minimum, maximum, values just inside/outside boundaries)
• Decision Tables: Systematically covering all combinations of conditions

White-box Testing

Tests with knowledge of the code’s internal structure, focusing on path coverage:

• Statement Coverage: Has every statement been executed?
• Branch Coverage: Has every branch been executed?

Gray-box Testing

A middle-ground approach between black-box and white-box testing. Uses partial knowledge of internal structure while testing through external inputs and outputs.

The Test Pyramid — Balancing Your Tests

Once you understand test types, the next key concept is the test pyramid, a model originally proposed by Mike Cohn in Succeeding with Agile (2009) and popularized by Martin Fowler’s writing. It illustrates the ideal balance of test quantity and type.

• Unit tests as the foundation: Fast execution, easy problem identification. Write hundreds to thousands
• Integration tests in the middle: Moderate coverage of component interactions
• E2E tests at the top: Slow execution and high maintenance cost, so focus on critical scenarios only

Maintaining this balance ensures a fast feedback loop while achieving sufficient test coverage.

Testing Methodologies — TDD and BDD

Beyond test types, it’s worth understanding development methodologies that leverage testing.

TDD (Test-Driven Development)

A development approach where tests are written before implementation. Development proceeds through the Red (write a failing test) → Green (write minimal code to pass) → Refactor cycle.

BDD (Behavior-Driven Development)

A methodology that integrates specifications and tests using Given / When / Then format. Since business requirements can be expressed directly as test cases, it’s effective for bridging the communication gap between developers and non-developers.

The Big Picture

Here’s how the entire software testing taxonomy fits together:

mindmap
  root((Software Testing))
    Test Levels
      Unit Testing
      Integration Testing
      System Testing
      System Integration Testing
      Acceptance Testing
    Test Types
      Functional Testing
        Regression Testing
        Smoke Testing
        Exploratory Testing
      Non-functional Testing
        Performance Testing
        Security Testing
        Accessibility Testing
    Test Design Techniques
      Black-box
      White-box
      Gray-box
    Testing Methodologies
      TDD
      BDD

Summary

Software testing spans many types, but organizing them along three axes — test levels (granularity), test types (purpose), and test design techniques (approach) — makes the landscape easy to understand.

In practice, the fundamental approach is to keep the test pyramid balance in mind: build automation around unit tests, protect quality with regression tests, and layer in non-functional tests (performance, security) as needed.

That’s all for this systematic guide to software testing types based on ISTQB, sent from the field.

References

Resource	URL
ISTQB Official Site	https://www.istqb.org/certifications/certified-tester-foundation-level
ISTQB Glossary	https://glossary.istqb.org/en_US/
JSTQB Foundation Level Syllabus	https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
ISO/IEC/IEEE 29119 (Testing Standard)	https://www.iso.org/standard/81291.html
Atlassian — Types of Software Testing	https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
Martin Fowler — Practical Test Pyramid	https://martinfowler.com/articles/practical-test-pyramid.html
Google Testing Blog	https://testing.googleblog.com
OWASP Testing Guide	https://owasp.org/www-project-web-security-testing-guide/
WCAG 2.1	https://www.w3.org/TR/WCAG21/