·
12 min
Functional testing in software: definition, techniques and automation
Roman Kirchmeier - Autemos
Functional testing in software checks whether a system performs the functions that its requirements, user stories or specifications define. It looks at observable behaviour, such as whether a transfer posts or a daily limit applies. The ISTQB syllabus treats it as one of four test types that can appear at all five test levels. How well a system does its job, such as how fast or how securely, is the subject of non-functional testing. Banks and other financial entities have to show supervisors that changes were tested before release.
TL;DR: Functional testing checks what software should do, measured against requirements and acceptance criteria. The ISTQB CTFL v4.0.1 syllabus lists it as one of four test types, applicable at five test levels from component testing to acceptance testing. Good test cases come from equivalence partitions, boundary values, decision tables and state transitions. Regression tests are a strong automation candidate.
Figure 1: Functional tests check what a system does, non-functional tests check how well it does it.
What is functional testing in software?
Functional testing is a test type that checks whether a component or system carries out its specified functions completely, correctly and appropriately. The ISTQB syllabus puts it this way: “Functional testing evaluates the functions that a component or system should perform. The functions are ‘what’ the test object should do.” (ISTQB CTFL Syllabus v4.0.1, 2024).
The syllabus names three objectives, “checking the functional completeness, functional correctness and functional appropriateness.” In online banking, that means:
Functional completeness: customers can create, change, schedule and cancel payment orders as specified.
Functional correctness: fees and exchange rates are right, and an order above the limit is rejected.
Functional appropriateness: a standard payment needs no pointless intermediate steps.
ISO/IEC 25010:2023 groups the same three sub-characteristics under functional suitability, the “capability of a product to provide functions that meet stated and implied needs of intended users when it is used under specified conditions” (ISO/IEC 25010:2023, 2023). Implied needs count: few user stories say a negative amount must be rejected.
Where this test type sits next to smoke tests, regression tests and other terms is covered in our overview of test types in software testing.
How does functional testing differ from non-functional testing?
Functional testing checks what a system does; non-functional testing checks how well it does it, measured against quality characteristics such as performance efficiency, security or usability. The ISTQB syllabus takes these characteristics from ISO/IEC 25010, as listed in the table below.
The November 2023 edition of the standard renamed two characteristics and added safety. Usability is now interaction capability and portability is now flexibility (ISO/IEC 25010:2023, 2023).
The syllabus notes that many non-functional tests are derived from the functional ones (ISTQB CTFL Syllabus v4.0.1, 2024). A load test often replays the same transfer flow and times it.
Criterion | Functional | Non-functional |
|---|---|---|
Guiding question | What does the system do? | How well does it do it? |
ISO/IEC 25010 characteristics | functional completeness, correctness, appropriateness | performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, safety |
Typical test basis | requirements, user stories, acceptance criteria | quality requirements, service level agreements |
Online banking example | a transfer above the daily limit is rejected | login stays responsive during month-end peaks |
Automatable with Autemos | Yes, for web, mobile, API and desktop | No for load, performance and security testing |
Autemos automates functional tests across web, mobile (iOS and Android), API (REST and SOAP) and desktop. Load and performance testing, security and penetration testing and code coverage measurement are outside its scope, so you need specialised tools for those jobs.
At which test levels do these tests run?
Functional testing happens at all five test levels in the current ISTQB syllabus: component testing, component integration testing, system testing, system integration testing and acceptance testing (ISTQB CTFL Syllabus v4.0.1, 2024). Many overviews still show four levels; v4.0.1 lists system integration testing as a separate one.
Figure 2: Functional tests run at all five ISTQB test levels.
Test level | Focus per ISTQB | Example at this level |
|---|---|---|
Component testing (unit testing) | components in isolation | the fee calculation returns the right amount for each account type |
Component integration testing | interfaces and interactions between components | the payment service hands orders to the booking module correctly |
System testing | overall behaviour and capabilities of the entire system | a customer opens a savings account in online banking |
System integration testing | interfaces to other systems and external services | a payment goes to the payment system and the status comes back |
Acceptance testing | readiness for deployment against the user's business needs | the business unit checks loan approval against acceptance criteria |
System testing may be performed by an independent test team, and acceptance testing should ideally be performed by the intended users. System integration testing needs a test environment close to the operational one.
Our article on system testing, its goals and process explains how it differs from integration testing. The guide to acceptance testing and UAT covers its forms, from UAT to regulatory acceptance testing. For a short introduction to all levels, see software testing fundamentals.
Is functional testing always black-box testing?
Checking functions isn't automatically black-box testing: the ISTQB syllabus lists functional, non-functional, black-box and white-box as four separate test types. It states that all four “can be applied to all test levels”, with a different focus at each level (ISTQB CTFL Syllabus v4.0.1, 2024).
Functional or non-functional says what gets tested: a function or a quality characteristic. Black-box or white-box says where the tests come from. Black-box testing “is specification-based and derives tests from documentation not related to the internal structure of the test object.” White-box testing uses code, architecture, work flows and data flows.
A white-box test of a function might check that every branch of a fee rule runs at least once and returns the right result. The syllabus names white-box techniques for higher test levels too, such as API testing. At system and acceptance level, the tests often come from specifications, which explains why people treat the two terms as one.
Our article compares black-box and white-box testing and when to use each.
Which techniques produce good test cases?
The ISTQB syllabus names four black-box test techniques for deriving test cases from specified behaviour: equivalence partitioning, boundary value analysis, decision table testing and state transition testing. Exhaustive testing is out of reach: “Testing everything is not feasible except in trivial cases (Manna 1978)” (ISTQB CTFL Syllabus v4.0.1, 2024).
Technique | Suited to | Payment order example |
|---|---|---|
Equivalence partitioning | values processed the same way | amount invalid (0 or negative), valid up to the limit, above the limit |
Boundary value analysis (2-value or 3-value) | ordered partitions | daily limit CHF 5000: 2-value tests 5000 and 5000.01, 3-value adds 4999.99 |
Decision table testing | business rules with several conditions | second approval depends on amount, beneficiary country and customer segment |
State transition testing | objects with defined states | order captured, approved, executed or cancelled |
With equivalence partitioning, one test per partition is enough, and partitions must not overlap. 3-value boundary value analysis is more rigorous and may detect defects that the 2-value version misses. If “x ≤ 10” is wrongly coded as “x = 10”, the 2-value test values 10 and 11 don't reveal it. The neighbour 9 is likely to expose it.
Decision tables record business rules, but the number of rules grows exponentially with the number of conditions. For state transition testing, the syllabus calls valid transitions coverage the most widely used criterion.
Use case testing is no longer one of the black-box techniques in CTFL v4.0.1; version 3.1 still listed it. The syllabus adds experience-based techniques (error guessing, exploratory testing, checklist-based testing) that can find defects the others miss. Our guide to equivalence partitioning and boundary value analysis shows the method step by step.
What does the test process look like, step by step?
Checking functions takes eight steps, from the test basis through test cases and test data to exit criteria, which define when the activity counts as complete. The usual starting point is acceptance criteria, which the ISTQB syllabus describes as the conditions an implementation of a user story must meet to be accepted by stakeholders (ISTQB CTFL Syllabus v4.0.1, 2024).
Figure 3: The process from test basis to exit criteria.
Review the test basis: read requirements, user stories and acceptance criteria, and resolve open questions.
Derive test conditions: record per requirement what gets tested, such as “an order above the limit is rejected”.
Design test cases and test data: set inputs and expected results with the techniques above.
Check entry criteria: environment, test data and a working build are ready, and smoke tests have passed.
Execute the tests: manually or automated, logging a result per test case.
Report deviations: document steps, expected and actual result, environment and data.
Run confirmation and regression tests: retest the fix and check that nothing else broke.
Evaluate exit criteria: compare coverage, unresolved defects and failed test cases with agreed thresholds.
The syllabus recommends defining entry and exit criteria for each test level. Running out of time or budget can count as an exit criterion if stakeholders accept the remaining risk.
Testable acceptance criteria in the ticket are the basis for the steps that follow. Step 7 repeats with each release, and our article on regression testing in software development covers how to build that suite.
Which tests should you automate first?
Automate functional regression tests for stable, business-critical flows first, and place each test at the lowest test level that still checks the behaviour meaningfully. The ISTQB syllabus says “regression testing is a strong candidate for automation” and that test automation “should start early in the project” (ISTQB CTFL Syllabus v4.0.1, 2024).
Ham Vocke advises: “Push your tests as far down the test pyramid as you can.” He describes tests that run through the entire stack as notoriously flaky (The Practical Test Pyramid, 2018). Google reported in 2016 that almost 16% of its tests showed some flakiness (Google Testing Blog, 2016).
Good candidates for automation:
regression tests for login, payments and account opening
tests with many data combinations from partitions and boundary values
checks of business rules through the API, below the user interface
tests that run in the CI/CD pipeline on every merge
Exploratory tests of new features and checks on UIs that still change weekly are better kept manual. In a controlled experiment with 51 students, Itkonen and Mäntylä found no significant difference in defect detection between exploratory and test-case-based testing, and exploratory testing needed less design effort (Empirical Software Engineering, 2014).
A study with industrial data from Siemens and Saab found that for automated GUI tests “maintenance costs can still be considerable” and that frequent maintenance is cheaper than big-bang maintenance (Alégroth, Feldt, Kolström, 2016). Garousi and Mäntylä conclude that when and what to automate depends on context, and that wrong decisions can get expensive (Information and Software Technology, 2016).
Autemos is an AI-assisted test automation platform from selementrix GmbH in Baar, Switzerland. Its AI Recorder drafts an executable test workflow from a Jira ticket, user story or plain-text test case; no AI-generated step runs until your team approves it. Web tests export as Playwright code (Java or TypeScript) and mobile tests as Appium (Java), so they run without Autemos.
Self-healing locators update selectors after UI changes and log every heal so your team can reverse it. That cuts locator upkeep; maintenance of test logic and test data remains. For pipeline setup, see our article on test automation in CI/CD.
What do FINMA and DORA require from software tests at banks?
FINMA Circular 2023/1 requires functional and non-functional requirements to be tested according to their criticality; DORA requires tested, approved and verified changes without naming any test type. Neither framework prescribes a specific tool or test automation.
The circular, in force since 1 January 2024, states in its change management section that functional and non-functional requirements are “klar definiert und genehmigt und gemäss ihrer Kritikalität getestet und validiert” (clearly defined and approved, and tested and confirmed as fit according to their criticality) (FINMA Circular 2023/1, 2022). The same section requires development or test environments to be kept separate from ICT production.
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025. Article 9(4)(e) requires that “all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner”. Under Article 24(6), financial entities other than microenterprises must test all ICT systems and applications supporting critical or important functions at least yearly (DORA on EUR-Lex, 2022).
Delegated Regulation (EU) 2024/1774 asks in Article 16 for a procedure “for the testing and approval of all ICT systems prior to their use and after maintenance”, with testing matched to the criticality of the business procedures and ICT assets (Delegated Regulation 2024/1774, 2024).
DORA binds financial entities in the EU; Swiss banks come into scope through EU subsidiaries or EU business. Our assessment: automated functional regression tests, linked to requirements in Jira/Xray and reported in Allure, are one way to produce the required evidence. Neither framework prescribes this route.
Which myths about this test type persist?
One persistent myth in software testing is the 1:10:100 rule, which says a defect costs ten times more in each later project phase. Menzies et al. studied 171 software projects from 2006 to 2014 and found no evidence for a general “delayed issue effect” (Empirical Software Engineering 22, 2017).
Figure 4: Common myths and what research, ISTQB and ISO/IEC 25010 say about them.
The authors conclude that the effect “should not be considered a global truism”. Individual late defects can still be expensive. Budgets justified with the 1:10:100 rule cite a ratio that this data doesn't confirm. Other myths concern terminology:
Common claim | What the sources say |
|---|---|
Defect costs follow the 1:10:100 rule | No evidence for a general effect across 171 projects (Menzies et al., 2017) |
Functional and black-box testing are the same | ISTQB lists them as separate test types |
Unit testing is a type of functional testing | Component testing is a test level where functional and non-functional tests run |
Usability belongs to functional suitability | Usability (interaction capability) is a non-functional characteristic in ISO/IEC 25010 |
Functional testing is a test level | In the ISTQB syllabus it is a test type |
There are four test levels | CTFL v4.0.1 describes five |
A team that plans a separate function-testing phase after integration testing may never test functions at component level.
Frequently asked questions
What is functional testing in software development?
Functional testing checks whether software performs the functions that requirements, user stories or acceptance criteria define. The ISTQB CTFL v4.0.1 syllabus names functional completeness, functional correctness and functional appropriateness as its main objectives. ISO/IEC 25010:2023 groups these three sub-characteristics under functional suitability.
What is the difference between functional testing and system testing?
Functional testing is a test type; system testing is a test level. Tests of functions run at all five ISTQB test levels. According to the syllabus, system testing focuses on the overall behaviour of an entire system and often includes both functional and non-functional checks.
Is a unit test a functional test?
A unit test runs at the component testing level and can be functional or non-functional. It is functional when it checks that a fee function calculates correctly, and non-functional when it measures how long a method takes. Unit testing is a test level, not a subtype of this test type.
Can these tests be automated?
Regression tests that repeat with every change are the best place to start with automation. The ISTQB syllabus calls regression testing a strong candidate for automation. Exploratory tests of new features usually stay manual, and a study with Siemens and Saab data shows automated GUI tests need ongoing maintenance.
Do DORA or FINMA require this kind of testing?
FINMA Circular 2023/1 requires functional and non-functional requirements to be tested according to their criticality. DORA names no test type, but it requires tested and approved changes and at least yearly tests of ICT systems supporting critical or important functions. Neither framework prescribes test automation.
Conclusion
This test type checks software behaviour against requirements and acceptance criteria, and it applies at all five ISTQB test levels. Useful test cases come from equivalence partitions, 2-value or 3-value boundary values, decision tables and state transitions.
Automate stable regression tests first, at the lowest level that still makes sense, and budget for maintenance from day one. Load, performance and security testing need their own tools; Autemos doesn't cover them. For banks, FINMA expects tests matched to criticality and DORA expects tested, approved changes.
If you'd like to see how Autemos drafts approval-gated test workflows from your Jira stories and links them to Xray, talk to the Autemos team.
