---
name: functional-testing
description: Use when asked to verify that an application's features work as specified — as the general discipline underlying more specific techniques (black-box testing, acceptance testing, UI automation) — as distinct from non-functional testing of quality attributes like performance or security (see performance-testing, security-testing).
---

# Functional Testing

Functional testing verifies that an application performs its intended
functions correctly — examining behavior against specified requirements
to confirm features work as expected from an end user's perspective, as
distinct from non-functional testing of quality attributes (performance,
security, and the rest of [[system-quality-attributes]]'s catalog).

## How automated functional tests work

Test scripts simulate user interactions with the interface — clicking,
entering data, navigating — and verify the appropriate responses occur.
Common frameworks: Selenium and Playwright for web (see
[[playwright-testing-with-javascript]] and siblings, and
[[selenium-testing-with-javascript]] and siblings, in this
collection), Appium for mobile, and dedicated API-testing tools for
backend services — written in whatever language the team's automation
stack uses.

## Benefits of automating it

Faster execution, better and more consistent coverage, and true
repeatability compared to manual testing. Wired into CI, automated
functional tests give immediate feedback the moment a code change
introduces a defect, substantially reducing the time a full regression
pass would otherwise take.

## The real cost

Automation isn't free: scripts need regular maintenance as the
application changes, and building/maintaining a real automation
framework needs skilled people and non-trivial upfront investment. That
investment pays off especially for applications with frequent releases
and substantial functionality, where the alternative (repeated manual
regression testing) would cost far more over time.

## Common pitfalls

- **Automating everything immediately** without weighing setup cost
  against release frequency — a low-change, rarely-released application
  may not justify full automation investment.
- **Letting scripts rot as the UI changes** — an unmaintained functional
  test suite becomes a source of false failures that teams learn to
  ignore, defeating its purpose.
- **Testing implementation detail instead of specified behavior** — see
  [[test-driven-development]]'s same warning; a functional test
  coupled to internal structure breaks on refactors that didn't change
  actual behavior.
- **Conflating functional coverage with full quality coverage** — passing
  functional tests says nothing about performance, security, or
  accessibility; those need their own dedicated testing.

## Learn more

- [[black-box-testing]] for the technique family most functional tests are designed with.
- [[acceptance-testing]] for the client/user-requirements-focused variant of functional verification.
- [[system-quality-attributes]] for the non-functional attributes functional testing deliberately doesn't cover.