Tech Notes Documentation
Insights, tutorials, and deep-dives into QA automation and software engineering.
ISTQB Software Testing Fundamentals: Test Levels, Test Types & Test Techniques
Software testing is a systematic activity used to evaluate a software product, identify defects, reduce risks, and provide stakeholders with information about its quality. A well-structured testing strategy does not rely on a single testing method. Instead, testers combine different test levels, test types, and test techniques according to the test object, objectives, risks, and available resources.
This article is based primarily on the ISTQB Certified Tester Foundation Level (CTFL) Syllabus v4.0.1 and relevant international software testing standards, including ISO/IEC/IEEE 29119-4:2021 for test techniques and ISO/IEC 25010 for software product quality. Examples and explanations in this article are simplified for educational purposes.
Testing Taxonomy: Test Levels, Test Types & Test Techniques
These concepts answer different questions:
| Concept | Main Question | Purpose |
|---|---|---|
| Test Levels | Where / at what level? | Defines the level of the test object being tested |
| Test Types | What is being evaluated? | Defines the focus of testing, such as functionality or quality characteristics |
| Test Techniques | How should test cases be derived? | Provides systematic ways to design effective test cases |
The three concepts can be combined. For example, a tester can perform system testing using functional testing while applying equivalence partitioning and boundary value analysis to design the test cases.
1 Test Levels
ISTQB CTFL v4.0.1 describes five test levels. A test level groups test activities that are organized and managed together and applies to software at a particular level of development.
1.1 Component Testing
Also known as Unit Testing, component testing focuses on testing individual components in isolation. A component can be a function, method, class, module, or another independently testable unit. Component testing is commonly performed by developers and often uses unit testing frameworks or other supporting tools.
calculateDiscount() function is tested with different input values to verify that it returns the expected discount amount.
Common tools include: PHPUnit, Jest, JUnit, NUnit, pytest.
1.2 Component Integration Testing
Component integration testing focuses on the interfaces and interactions between components. The purpose is to verify that individual components communicate correctly after they are integrated.
↓
Pricing Service
↓
Inventory Service
The test verifies that the components exchange the expected data and handle integration errors correctly.
1.3 System Testing
System testing evaluates the overall behavior and capabilities of an entire system or product. It can include both functional and non-functional testing. End-to-end tasks are often included in system testing, particularly when validating complete user flows.
A representative test environment may be particularly important when evaluating certain non-functional quality characteristics.
1.4 System Integration Testing
System integration testing focuses on the interfaces and interactions between the system under test and other systems or external services. This is different from component integration testing:
- Component Integration: Component A ↔ Component B
- System Integration: System Under Test ↔ External System / Service
1.5 Acceptance Testing
Acceptance testing focuses on validation and demonstrating readiness for deployment. Its purpose is to determine whether the system fulfills the intended users' business needs. Ideally, acceptance testing involves the intended users or representatives of the business.
- User Acceptance Testing (UAT)
- Operational Acceptance Testing
- Contractual / Regulatory Acceptance Testing
- Alpha / Beta Testing
Example: A business team verifies that an invoicing application supports the required billing workflow, business rules, and approval process before deployment.
2 Test Types
Test types are groups of test activities related to specific quality characteristics or testing objectives. According to CTFL v4.0.1, the four test types are, but hybrid types are also common in the industry:
2.1 Functional Testing
Functional testing evaluates what the software should do. The primary focus is on whether the functions correctly implement the specified behavior.
Product A ($50) + Product B ($30) + Shipping ($10) = Expected Total ($90).
2.2 Non-Functional Testing
Non-functional testing evaluates how well the system behaves rather than only what it does. The CTFL v4.0.1 syllabus identifies characteristics such as:
- Performance efficiency: Does the application respond within the specified response time under expected load?
- Compatibility: Does the application work correctly across supported browsers, operating systems, devices, and configurations?
- Usability / interaction capability: Can intended users complete tasks effectively and efficiently?
- Security: Does the system adequately protect information and resist unauthorized access?
- Reliability: Does the system continue to perform consistently under specified conditions?
2.3 Black-Box Testing
Black-box testing is specification-based testing. The tester derives tests from documentation without relying on knowledge of the internal structure of the test object.
Valid username + valid password → Login succeeds
Invalid username + valid password → Login fails
The tester does not need to know how authentication is implemented internally to derive these tests.
2.4 White-Box Testing
White-box testing is structure-based testing. The tester derives tests using knowledge of the internal structure or implementation of the test object, such as source code or architecture.
IF statement.
2.5 Gray-Box Testing
Testing that combines external behavioral testing (Black-Box) with partial knowledge of the internal structure, such as databases or APIs (White-Box). Although not an official category in CTFL v4.0.1, it is highly prevalent in the industry.
3 Confirmation, Regression, Smoke, & Sanity Testing
Software changes may introduce defects, or new builds might be unstable. Therefore, testing after a change or a new release commonly involves these activities:
3.1 Confirmation Testing
Confirmation testing verifies that an originally reported defect has been successfully fixed. It is sometimes called re-testing in industry.
3.2 Regression Testing
Regression testing verifies that a change has not caused adverse consequences or side-effects elsewhere in the system.
3.3 Smoke Testing
Also known as Build Verification Testing. A quick, shallow set of tests on core features to ensure the application doesn't crash severely before deeper testing begins.
3.4 Sanity Testing
A narrow but deep verification focused on a specific area that was just fixed or modified, ensuring it works as expected (often acting as a subset of regression testing).
4 Test Design Techniques
Test design techniques provide systematic ways to derive test conditions, test cases, and test data. They help testers achieve useful coverage without having to test every possible input combination.
4.1 Black-Box Test Techniques
-
Equivalence Partitioning: Divide data into equivalence partitions where the test object is expected to process the values in the same way.
Partition (Age 18-65) Example Value Classification Below 18 17 Invalid 18 - 65 30 Valid Above 65 66 Invalid -
Boundary Value Analysis (BVA): Test values at or around the boundaries of equivalence partitions.
2-Value BVA: Test boundary value and its closest neighbor.
3-Value BVA: Test boundary value, closest neighbor on one side, and closest neighbor on the other side. - Decision Table Testing: Useful when system behavior depends on combinations of conditions. Example: A promotion is applied only when Is VIP? = Yes AND Cart Total > $100.
- State Transition Testing: Useful when system behavior depends on current state and events that cause the system to move from one state to another. Example: Active → Invalid PIN → Locked.
- Use Case Testing: Deriving tests based on real-world interactions (use cases) between an actor and the system, designing for main success scenarios and exception paths. (Note: this technique was moved to the Advanced Level in CTFL v4.0.1).
4.2 White-Box Test Techniques
-
Statement Testing & Statement Coverage: Designs test cases to exercise executable statements in the code.
Statement Coverage = (Executed Statements / Total Statements) × 100% - Branch Testing & Branch Coverage: Designs test cases to exercise branches in the control flow.
- Path Testing & Coverage: Designing tests to execute specific sequences of statements (paths) from the entry to the exit of a software function. This involves testing combinations of branches.
4.3 Experience-Based Test Techniques
- Error Guessing: Used to anticipate where errors, defects, and failures may occur based on the tester's knowledge.
- Exploratory Testing: An approach in which test design, test execution, and learning happen concurrently.
- Checklist-Based Testing: Uses a checklist of test conditions as a guide for designing, implementing, and executing tests.
5 Collaboration-Based Test Approaches
Test design is not limited to deriving test cases from existing specifications. CTFL v4.0.1 also discusses collaboration-based test approaches, where testers, developers, and business representatives collaborate to prevent defects and improve shared understanding. Examples include Collaborative user story writing and Acceptance Test-Driven Development (ATDD).
6 Risk-Based Testing
Testing resources are always limited. Risk-based testing helps prioritize testing according to the risks associated with the product (Risk ≈ Likelihood × Impact). High-risk areas (e.g., Payment module) generally deserve more attention and test depth.
7 Putting Everything Together
A practical testing strategy can combine all of these concepts. For example, consider an online payment system:
↓
TEST TYPES: Functional + Non-Functional + Gray-Box
↓
TEST TECHNIQUES: Equivalence Partitioning, BVA, Decision Table, State Transition
↓
EXPERIENCE-BASED SUPPORT: Error Guessing, Exploratory Testing
↓
CHANGE-RELATED TESTING: Smoke, Sanity, Confirmation, & Regression Testing
↓
RISK-BASED PRIORITIZATION: Highest-risk payment scenarios tested with greater depth.
8 Quick Reference
| Category | Examples |
|---|---|
| Test Levels | Component, Component Integration, System, System Integration, Acceptance |
| Test Types | Functional, Non-Functional, Black-Box, White-Box, Gray-Box |
| Black-Box Techniques | Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Case Testing |
| White-Box Techniques | Statement Testing, Branch Testing, Path Testing |
| Experience-Based | Error Guessing, Exploratory Testing, Checklist-Based Testing |
| Change-Related / Post-Build | Smoke Testing, Sanity Testing, Confirmation Testing, Regression Testing |
9 Final Takeaway
Effective software testing is not about executing the largest possible number of test cases. It is about selecting appropriate test levels, test types, test techniques, and test priorities to obtain useful coverage and detect important defects within available resources.
- Test Level WHERE / AT WHAT LEVEL?
- Test Type WHAT IS BEING EVALUATED?
- Test Technique HOW ARE TEST CASES DESIGNED?
- Risk-Based Testing WHERE SHOULD TESTING EFFORT BE PRIORITIZED?
References
- International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus v4.0.1, 2024.
- ISO/IEC/IEEE 29119-4:2021. Software and systems engineering — Software testing — Part 4: Test techniques.
- ISO/IEC 25010:2023. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model.