Functional testing
Every testable requirement boils down to a simple statement: given this input, the application should produce that output. Functional testing is the discipline of checking exactly that, feature by feature, against whatever the requirements or user stories actually say should happen. It's not concerned with how fast a feature runs or how well it holds up under attack, those are questions for other kinds of testing entirely, functional testing only asks whether the feature works.
In practice, that means starting from a requirement and working out which inputs actually matter to test. Rather than trying every possible value, testers group inputs into equivalence classes that should behave the same way, and pay particular attention to boundary values, the edges where behavior is most likely to break, like the first invalid value just past a valid range. Each test traces back to a specific expected behavior, so a failing test points at exactly what broke and why.
The term usually refers to testing at the feature or system level rather than a single function in isolation. Checking that a login form rejects a bad password is functional testing. Checking that a complete checkout flow correctly totals an order, applies a discount, and charges the right amount is functional testing too, even though it touches several pieces of code working together behind the scenes.
How it's approached
- Start from a requirement or user story, tracing each test back to a specific expected behavior.
- Group inputs into equivalence classes rather than testing every possible value individually.
- Pay particular attention to boundary values, the edges where behavior is most likely to break.
- Run manually or automate UI-level checks with a tool like Selenium or Playwright.
- Stay distinct from non-functional testing, which checks performance, security, or usability instead of correctness.
Where it shows up
- Confirming a login form accepts valid credentials and rejects invalid ones with the right error.
- Checking that a checkout process correctly calculates a total, including tax and discounts.
- Verifying a search feature returns results that actually match the query entered.
- Testing that a form validates required fields before allowing a submission to go through.
Benefits and challenges
| Benefit | Challenge |
|---|---|
| Directly verifies the thing users actually care about, whether a feature works the way it's supposed to. | Says nothing about how the feature performs under load or whether it's secure, that's a separate kind of testing entirely. |
| Traceable back to a specific requirement, so a failing test points at exactly what broke. | Requirements change, and a suite that isn't kept in sync with them quickly starts testing an outdated version of the feature. |
| Can be automated at the UI level, giving repeatable coverage of a feature's core behavior. | Covering every meaningful input combination takes real planning, testing only the obvious happy path leaves real gaps. |
Frequently asked questions
What's the difference between functional and non-functional testing?
Functional testing checks whether a feature behaves the way it's supposed to, given a certain input. Non-functional testing checks everything else about how it behaves, how fast it responds, how it holds up under load, how secure it is, none of which is about whether the feature is technically correct.
Is functional testing the same as unit testing?
Not quite, though they overlap. Unit testing checks a single function or piece of code in isolation. Functional testing usually operates at the level of a complete feature or user-facing behavior, like a full checkout flow, which might involve several units working together.
Can functional testing be automated?
Yes, and it commonly is, especially at the UI level using tools like Selenium or Playwright. Manual functional testing still shows up for newer or less stable features, where writing an automated check before the feature settles down isn't worth the upfront cost.
How Klarent helps
Klarent's AI agents generate functional tests directly from a plain-language description of a feature, covering the inputs and edge cases a requirement actually calls for, and keep those tests passing through interface changes with self-healing execution, alongside visual regression testing that catches the visual changes functional checks miss.