Functional testing checks that the software does what it is supposed to do. Give it an input, and the right thing happens. Non-functional testing asks a different question about the same software: how well it does it.
The short version: a functional test takes a requirement, exercises the software against it, and compares what happened with what should have happened. It doesn't care how the code is built, which is why the standards file it alongside black-box testing. It happens at every level. A unit test checking a function returns the right total is functional, and so is a tester logging in as two users to check an encrypted file goes from one to the other. What's new in 2026 is that the feature and its tests often come from one agent's reading of one ticket, so a green suite shows the agent agreed with itself. Functional testing is where someone else gets to check the reading.
Functional testing in software testing: the definitions
The ISTQB glossary defines functional testing as testing performed to evaluate if a component or system satisfies functional requirements. Short, and it puts the weight on the word "requirements": without one, there is nothing to test against.
The ISTQB Foundation syllabus v4.0.1 draws the line more usefully. "Functional testing evaluates the functions that a component or system should perform," it says. "The functions are "what" the test object should do." Non-functional testing, by contrast, "is the testing of "how well the system behaves"."
What vs how well. That distinction is the whole thing, and most of the confusion downstream comes from people reaching for a different axis instead, usually the one about whether you can see the code.
The quality characteristic functional testing is aimed at is functional suitability, which comes from ISO/IEC 25010, the product quality model, in its second edition published in November 2023. It has three parts, and they work as a checklist for what a functional test is actually looking for:
Functional completeness. Does the set of functions cover everything the users were promised? The feature that was in the ticket and never got built fails here, and no amount of testing the parts that were built will catch it.
Functional correctness. Does each function give the right result? The report that renders but shows the wrong total fails here.
Functional appropriateness. Do the functions help the user do the task, or just technically exist? A checkout that accepts payment but makes the user re-enter their address three times fails here. It's the part most test plans skip, because the requirement never said "and don't make it annoying."
Functional vs non-functional testing
| Functional testing | Non-functional testing | |
|---|---|---|
| Question | Does it do what it should? | How well does it do it? |
| Checked against | Functional requirements, acceptance criteria, the spec | Quality characteristics: performance efficiency, reliability, security, usability, compatibility, maintainability, portability, safety |
| Typical tests | Unit, integration, system and acceptance tests of features; smoke and regression runs of existing features; E2E of a user journey | Load and performance, security and penetration, accessibility, usability, compatibility across browsers and devices |
| Result | Pass or fail against an expected outcome | Usually a measurement against a threshold: response under 300 ms, no critical findings, WCAG AA |
| Written from | What the user should be able to do | How the system should behave while the user does it |
The two overlap more than the table suggests. The syllabus notes that "Many non-functional tests are derived from functional tests as they use the same functional tests" – you run the same flow and check that, while the function works, a constraint holds, such as a time limit.
A head of engineering showed us the overlap live during a product demo. Looking at a screenshot the agent had taken, he asked: "Does it come back that the visibility in dark mode is horrible? Because if you go to the picture, you see that the contrast is really bad on the left side on the menu." The functional test had passed. The non-functional observation came from a person reading the same run's screenshot, and he wanted both.
One naming wrinkle worth knowing. The non-functional list above uses the syllabus's names. The 2023 edition of ISO 25010 renamed usability to "interaction capability" and portability to "flexibility", and brought the total to nine characteristics. The syllabus keeps the older names with an "also known as", so you will meet both sets in the wild.
Types of functional testing
Functional testing is a test type, and it applies at every test level. Most lists get this wrong.
The ISTQB syllabus describes five test levels: component (unit), component integration, system, system integration, and acceptance. It describes four test types: functional, non-functional, black-box and white-box. And it says plainly that "All the four above mentioned test types can be applied to all test levels."
So unit testing is not a type of functional testing. A unit test is functional when it checks that a function returns the right result for an input, and structural when it checks that every branch ran. Both are unit tests.
With that in mind, here is where the kinds of testing most guides file under "functional" actually sit.
Functional testing at each level. Unit tests of a function's output. Integration tests that two components exchange the right data. System tests of a whole feature, which the syllabus describes as focusing on the behaviour of an entire system or product, "often including functional testing of end-to-end tasks". Acceptance tests, where the user or customer decides whether to accept the system. End-to-end testing is the functional testing of a business process from start to finish, in a production-like environment; we cover it separately in what is end-to-end testing.
Change-related testing. The ISTQB calls regression and confirmation testing "change-related": confirmation testing checks that a specific fix worked, and regression testing checks that the change didn't break anything unchanged. Both reuse functional tests. A regression suite is mostly functional tests you've decided to keep running.
Readiness checks. A smoke test is a short run over the most important paths, done to decide whether a build is worth testing properly at all. Sanity testing isn't a formal term; in practice it means a narrow re-check after a small change.
A test manager whose business users still test releases by hand drew that line precisely when we asked what she wanted automated first: "It's more like a smoke test. It's not a regression test. That we should do too, but it's actually just a smoke test. It takes 30 minutes of the tester's time, but they are so simple cases that they should and could be automated [...]. Those things that we want to always check that they work."
What a functional test looks like
The standards stay abstract, and the tests people describe to us don't.
A QA lead at a security software company gave us the shape of one in a sentence: "one user needs to login, do something, encrypt some information, send the mail or share the encrypted file, and another user should login and read that encrypted file. And you need to make sure that the encrypt happened and everything delivered securely or not." Two users, one artefact and a defined outcome, with nothing said about how the encryption is implemented.
The shortest version came from a QA engineer whose product is pricing analytics. She listed tables, reports, widgets, charts, and then: "it's still like just the end result which users see."
What both have in common, and what makes a functional test work, is the expected result rather than the steps. A tester at a transport company who'd spent two weeks writing goal-based tests for an agent found this out the slow way. Her early tests had clear steps and then "started failing after a while anyway and I had to add verification points. [...] When you have logged in, that you are logged in, and things like that." A test that says what to do but not what should be true afterwards is a walkthrough.
A good functional test states a goal, written as what a user is trying to achieve; the data or state it needs; and the observable result that means it passed, specific enough that a different person would reach the same verdict. Write the negative case too: the same goal with the wrong input, and what the software should refuse to do.
How functional testing is done
The textbook process is five steps. Identify the functions from the requirements, work out the inputs and the expected outputs, build the test data, run the tests, compare results and raise defects. Every guide has a version of it. The step that actually decides whether functional testing works is the first one, and it's the one with no tooling.
The CEO of a healthcare software company with a nine-person QA team described the failure: "it might look like everything is green. But it actually wasn't working in production because maybe we were interpreting it incorrectly, or maybe it was implemented wrong." His fix was to put the interpretation on the record: "the Jira ticket has to explain what that feature was, and then I have to compile and look at the two together and say, okay, this is how it's supposed to work." The requirement is the test oracle.
A QA manager with two offshore testers described the opposite failure, where the requirement is taken too literally: "when told this is the only impact place, that's all they check. And that's fine. They're good at checking that spot, but they're not good at, especially as more developers are starting to utilize AI more, they're not necessarily aware of all their changes." Scope the test to what the developer said they changed and you inherit the developer's blind spots.
On manual versus automated: the World Quality Report 2025-26, from 2,000 executives across 23 countries, puts the average share of automated test cases at 33%, and says around one in four new test scripts is AI-generated. The teams we talk to are around that mark.
An engineering lead with four or five manual testers described a 60/40 split, with the manual side carrying the new features because "E2E mainly focuses on the feature itself, whether it's working or not, and also some regression cases that we are aware of." A founding engineer at a startup with no QA function described the manual side with nobody owning it: a ticket moves to the testing column "and then someone would pick it up somewhere. Sometimes it's a developer, sometimes it's a CEO, sometimes it's another salesperson, and it's quite chaotic."
Functional testing when an agent writes the code
DORA's 2025 report, from nearly 5,000 respondents, found that "AI adoption does continue to have a negative relationship with software delivery stability," even while it observed a positive relationship between AI adoption and both delivery throughput and product performance. In the Stack Overflow 2026 survey, 58% of respondents who use AI use it for writing or improving tests.
The agent reads the ticket, builds the feature and writes the tests, and those tests are functional in form: input, expected output, pass. What they can't check is the reading of the ticket they came from, because the feature came from the same reading. Against the three parts of functional suitability:
Completeness is the gap the agent's own tests can't see, because a test for the function that wasn't built doesn't exist. The product lead whose team rebuilt a web portal with AI assistance told us the defects they found afterwards were mostly "things that weren't being built, so to say."
Correctness is where the agent's tests do work, within the agent's interpretation. If it misread "monthly total" as calendar month and the ticket meant billing month, the tests pass and the function is wrong.
Appropriateness is the one the ticket rarely writes down, so the agent's tests rarely check it.
Daniel Mauno Pettersson, our co-founder and CEO, describes where functional bugs actually live, and it's rarely the happy path: "complexity usually lies in all the different permutations of the product. So the base product might be simple, but then you add different types of roles, different types of users, different types of feature flags, or whatever it might be. And that's usually where you start finding bugs."
His description of what a functional tester does with a requirement is the same whether the tester is a person or an agent: "they would read the requirements, combine that with their experience and their product understanding, and then, based on that, try to break it or figure out if something is not working."
That's the shape of functional testing that holds up when an agent wrote the code. Derived from the intent, run against the working product, judged by a party with no stake in how the feature was built. In the standards' terms this is the validation half of verification and validation.
It won't cover all three parts of functional suitability. Whether an interface feels right to use is still a person's call, and a review of the diff is still the place to find out whether the code is clean, which is a different question with different tools. What it does cover is completeness and correctness against the ticket.
On QA.tech, an AI testing platform, a test case is a goal and an expected result in plain language, with the steps left to the agent. A change review on the pull request reads the linked ticket's acceptance criteria when the branch or PR carries the Jira or Linear key, exercises the affected flows on the preview build, and posts a pass, a fail, or unable to verify.
Review catches bad code. Verification catches broken products.
Functional testing and the terms it gets confused with
Functional testing vs end-to-end testing. E2E is functional testing of a whole business process, start to finish, in a production-like environment. Nearly every E2E test is functional; most functional tests are narrower than E2E.
Functional testing vs regression testing. Regression testing is change-related: it re-runs existing tests after a change. The tests it re-runs are mostly functional.
Functional testing vs acceptance testing. Acceptance is a level, the last one, where the customer or user decides whether to accept the system. Most of what runs there is functional testing.
Functional testing vs black-box testing. The ISTQB lists these as two of its four test types, not as synonyms, and the distinction is worth holding on to. Functional describes what you are checking. Black-box describes how much of the implementation you can see while you check it. Most functional tests are written from the specification without looking at the code, which is why the two get used interchangeably, but a test written with full knowledge of the code can still be a functional test.
FAQ
What is functional testing in software testing? Functional testing checks that a component or system does what its requirements say it should. The ISTQB defines it as testing performed to evaluate if a component or system satisfies functional requirements, and the Foundation syllabus puts it more plainly: the functions are "what" the test object should do. Give the software an input, compare the result with what was specified.
What is the difference between functional and non-functional testing? Functional testing asks whether the software does what it should. Non-functional testing asks how well it does it: performance, reliability, security, usability, compatibility, maintainability, portability and safety, the quality characteristics as the ISTQB syllabus lists them from ISO/IEC 25010. The same user flow can be the basis for both. A functional test checks the order goes through; a non-functional test checks it does so in under two seconds.
Is regression testing part of functional testing? Not as a type. The ISTQB files regression testing under change-related testing, because what triggers it is a change rather than a kind of requirement. What runs in a regression suite is mostly functional tests, so in practice the two overlap almost completely, though you could re-run a performance test after a change and call that regression testing too.
Is unit testing functional testing? Unit testing is a test level, not a type. A unit test is functional when it checks that a function returns the right output for a given input, and structural (white-box) when it checks that the code's branches were executed. Most unit tests are functional in form.
Is API testing functional testing? Usually. An API test submits a request and checks the response against the specification, which is functional testing through a programmatic interface. API tests can also be non-functional, for example load tests that measure response time under concurrency.
Can functional testing be automated? Yes, and most regression-level functional testing is the first thing teams automate. Across the industry about a third of test cases are automated on average, according to the World Quality Report 2025-26. Functional testing of new features is harder to automate because the requirement has to be interpreted first. Goal-based agentic tests, which take a plain-language goal and expected result rather than a script, are one answer to that.
Is functional testing the same as black-box testing? No, though they travel together. The ISTQB treats functional and black-box as two separate test types. Functional is what you check; black-box is what you can see while checking it. Most functional testing happens to be black-box, because it is written from the specification, but a test written with the code open in front of you can still be functional.