2.4 Test Types: Functional, Non-Functional, White-Box, and Change-Related
Key Takeaways
- A test type groups test activities by a shared objective: functional behavior, non-functional quality characteristics, internal structure (white-box), or the effects of change.
- Functional testing evaluates what the system does (functional completeness, correctness, appropriateness); non-functional testing evaluates how well it behaves against quality characteristics.
- The ISO 25010 quality model lists non-functional characteristics: performance efficiency, compatibility, usability, reliability, security, maintainability, portability, and functional suitability.
- Black-box testing derives tests from behavior/specifications without knowing internals; white-box testing derives tests from internal structure and measures statement and branch coverage.
- Change-related testing comprises confirmation testing (the fix worked) and regression testing (nothing else broke); any test type can be performed at any test level.
A Test Type Is Defined by Its Objective
A test type is a group of test activities related to specific quality characteristics, and most of those activities can be performed at every test level. CTFL v4.0 distinguishes four broad categories: functional, non-functional, black-box versus white-box (perspective-based), and change-related testing. Telling them apart is one of the most heavily examined topics in Chapter 2.
Functional testing evaluates the functions that the test object should perform — what the system does. The test basis is functions and features described in business requirements, specifications, use cases, epics, and user stories. ). Examples: a discount is computed correctly, a search returns matching results, a claim can be submitted. , the percentage of requirements covered by tests.
Non-Functional Testing and the ISO 25010 Characteristics
Non-functional testing evaluates how well the system behaves — its quality characteristics. CTFL v4.0 references the ISO/IEC 25010 product quality model. A feature can be functionally correct yet non-functionally unacceptable (e.g., correct but far too slow). Non-functional testing should be considered early, because these characteristics often drive architecture and are expensive to fix late.
| ISO 25010 characteristic | Non-functional question it answers |
|---|---|
| Performance efficiency | Is response time, throughput, and resource use acceptable? |
| Compatibility | Does it coexist and interoperate with other systems? |
| Usability | Is it easy and satisfying to learn and operate? |
| Reliability | Does it keep working under stated conditions/over time? |
| Security | Are data and functions protected against threats? |
| Maintainability | Can it be modified, tested, and analyzed easily? |
| Portability | Can it be moved to other environments/platforms? |
Black-Box Versus White-Box Testing
The perspective from which tests are derived gives two more types. Black-box testing (specification-based) derives tests from the documented behavior of the test object without reference to its internal structure — it checks behavior against the specification. White-box testing (structure-based) derives tests from the system's internal structure or implementation: code, architecture, control flow, or data flow. The defining feature of white-box testing is use of internal structure, not who performs it; a tester who designs tests from coverage data is doing white-box testing.
White-box testing measures structural coverage. The two CTFL v4.0 measures are:
- Statement coverage = (executed statements ÷ total statements) × 100%. 100% statement coverage means every line ran at least once.
- Branch coverage = (executed branches ÷ total branches) × 100%. 100% branch coverage means every decision outcome (true and false) was exercised; it subsumes statement coverage.
100% branch coverage guarantees 100% statement coverage, but not vice versa — a classic exam point.
Change-Related Testing and Avoiding the Type/Level Mix-Up
Change-related testing is performed after a change. Confirmation testing (retesting) verifies that a reported defect has actually been fixed by re-running the failing scenario. Regression testing verifies that a change has not adversely affected previously working, unchanged areas. These two often run together after a fix but answer different questions.
Remember that any test type can be applied at any test level: you can run functional, non-functional, white-box, and change-related tests at component, integration, system, or acceptance level. A frequent trap is treating white-box as developer-only or non-functional as a late-only afterthought. Another trap is assuming a single test maps to exactly one type — pick the best answer based on the dominant objective: correct behavior → functional; a quality characteristic → non-functional; internal structure/coverage → white-box; verifying a fix or guarding against side effects → change-related.
Type Versus Level: A Two-Dimensional Grid
The single most common confusion the exam exploits is mixing type (the objective) with level (where testing is organized). Picture them as two independent axes of a grid: the rows are the test types and the columns are the test levels, and almost every cell is valid.
| Type \ Level | Component | Integration | System | Acceptance |
|---|---|---|---|---|
| Functional | unit behavior | interface behavior | end-to-end behavior | business behavior |
| Non-functional | unit performance | interface throughput | load/usability/security | operational readiness |
| White-box | branch coverage | call coverage | architecture/config paths | rarely used |
| Change-related | retest fixed unit | retest interface | regression of workflows | confirm acceptance fix |
Reading the grid prevents wrong answers such as "performance testing is a test level" (it is a non-functional type, applicable at several levels) or "acceptance testing is a test type" (it is a level). When a question describes both a scope and an objective, decide each axis separately, then choose the option that matches what the question actually asks for.
Worked Example and Exam Tactics
" The dominant clue is internal structure (control-flow graph, decision outcomes) → white-box testing, specifically aiming at branch coverage. The fact that a password routine is "functional" in spirit is a distractor; the technique derives from structure, so the type is white-box. Now change the scenario to "a tester checks that valid and invalid passwords are accepted or rejected per the specification, without looking at the code" → that is black-box (functional) testing of the same routine. Same feature, different type, decided purely by the basis of the tests.
A further tactic: when an option claims a type is restricted to one level or one role ("white-box testing is only for developers," "non-functional testing only happens during acceptance"), it is almost always the wrong answer, because CTFL v4.0 states that test types can be applied at any level and are defined by objective, not by who performs them.
A suite achieves 100% statement coverage but only 70% branch coverage on a module containing several if-statements. What can you correctly conclude?
A test verifies that a report page loads within two seconds for 1,000 concurrent users. Which test type and ISO 25010 characteristic does it primarily represent?
Which statements about test types are correct per CTFL v4.0?
Select all that apply