Non-Functional Testing: Performance, Security, Accessibility

Functional testing asks "does it do the thing?" Non-functional testing asks "how well does it do the thing, and does it hold up under pressure?" These qualities rarely reduce to a single pass/fail, they need their own tools and expertise, and they're the ones teams most often defer until a user — or an auditor — complains.

Performance testing

Performance testing has several distinct flavours, and they answer different questions:

Load testing — does the system meet its response-time and throughput targets at expected peak traffic? Run it against a realistic traffic model, not a flat request rate.
Stress testing — push past expected load until something breaks. The goal isn't the breaking point itself; it's how it breaks. Does it shed load gracefully and recover, or does it fall over and stay down?
Soak testing — hold a moderate load for hours or days to expose slow degradation: memory leaks, connection-pool exhaustion, disk filling with logs, caches that never evict.
Spike testing — a sudden jump from low to very high traffic (a launch, a marketing email) and back. Autoscaling and queue behaviour are what you're watching.
Front-end performance — page load, time to interactive, largest contentful paint, bundle size, layout shift. Increasingly business-critical because it affects conversion and search ranking, and increasingly regressed by an innocuous dependency bump.

Server-side performance testing needs a production-like environment at production-like scale to mean anything — see test environments and data. Set explicit budgets ("p95 under 300ms", "bundle under 250KB") and fail CI when they regress, so performance doesn't erode one unnoticed change at a time.

Security testing

Security testing is layered, and most of the early layers can be automated in CI:

Dependency scanning (SCA) — known vulnerabilities in the libraries you pull in. Cheap, high-value, automate it on every build and on a schedule (new CVEs land against code you already shipped).
Static analysis (SAST) — insecure patterns in your own code: unsanitised input reaching a query, secrets committed to the repo, unsafe deserialisation.
Dynamic analysis (DAST) — probing the running application for injection, authentication bypass, misconfigured headers, exposed endpoints.
Authorisation testing — can a user reach data or actions above their permission level? Can a user in one tenant see another tenant's data? This overlaps heavily with functional testing of auth flows, and a broken check here is an incident, not a bug.
Penetration testing — periodic, human-led, deeper than any scanner. Typically annual or per-major-release, often by an outside firm.

Accessibility testing

Accessibility (usually targeting WCAG 2.1 or 2.2 level AA) is part automatable, part not:

Automated checks — tools like axe catch a meaningful slice: missing alt text, insufficient colour contrast, missing form labels, invalid or misused ARIA, missing landmark regions. Run these in CI on key pages and components.
Keyboard navigation — can every interactive element be reached and operated with the keyboard alone, in a sensible order, with a visible focus indicator? Can you escape every modal? This is a quick manual pass that catches a lot.
Screen reader testing — does the page make sense read aloud, in order, with controls announced correctly? This genuinely needs a person using a screen reader; no tool does it.

Automated tools find only a portion of accessibility issues — estimates range from about a third to half, depending on the tool and the study. The rest — meaningful reading order, sensible announcements, whether a custom component is actually usable — need manual testing with assistive technology.

Where autonomous testing helps (and where it doesn't)

An autonomous run is primarily functional — it checks that flows work — but because it drives the real application it surfaces some non-functional signals as a by-product: pages that error under real navigation, obviously broken rendering, flows that hang, console errors that hint at a leak. It also captures the screenshots that make an accessibility or visual review faster.

What it does not do is replace dedicated load testing, a security scan, or a screen-reader pass. Think of it as catching the gross failures that those specialised passes assume are already handled, not as covering their ground.

The takeaway

Non-functional testing covers how well the system performs, resists attack, and serves everyone — qualities with no single pass/fail. Automate the parts that automate well (dependency and static scans, performance budgets in CI, accessibility linting) and reserve scarce human and specialist effort for load-behaviour analysis, penetration testing, and screen-reader testing. Part 14 pulls back to place autonomous testing in the full picture the course has built.