When and How to Plan Non-Functional Testing

The most common mistake in non-functional testing is timing. Teams finish a feature, ship it, and then — sometimes weeks later, sometimes after a production incident — run a performance test or an accessibility audit. The problems they find at that point are expensive: a performance issue may require architectural changes; a security vulnerability may need a full code audit; accessibility failures baked into a component library affect every screen that uses it.

Non-functional testing done late is non-functional testing done expensively. The fix is planning it from the start.

Non-functional requirements: the missing conversation

Every functional requirement gets written down somewhere — a user story, an acceptance criterion, a spec. Non-functional requirements (NFRs) often do not. They are assumed. "The app should be fast." "It should be secure." "It should work on mobile." These are not requirements — they are hopes.

Testable NFRs look different:

• "The checkout API must respond within 500ms at the 95th percentile under 200 concurrent users in production."
• "All user-facing forms must meet WCAG 2.1 Level AA compliance."
• "The application must remain available with no more than 0.1% error rate during a 2× peak traffic spike lasting 10 minutes."

Without that level of specificity, you cannot write a test, and you cannot call a result a pass or a fail. The first step in planning non-functional testing is converting vague quality hopes into measurable requirements.

When to act at each SDLC phase

Prioritising what to test

You will not have infinite time for non-functional testing. The right approach is risk-based: focus effort where failure would hurt most.

Must have for most products:

• Security testing — data breaches are not recoverable business events
• Basic performance testing — outages on launch day are career-defining moments
• Accessibility testing — legal risk is real in the EU, US, and UK; user exclusion is always real

Should have for most products:

• Comprehensive performance tests across all test types (load, stress, spike, soak)
• Cross-browser and cross-device compatibility
• Internationalisation and localisation, if you serve multiple regions

Could have, depending on your product and audience:

• Chaos engineering and disaster recovery testing
• Deep compatibility with niche browsers or legacy environments
• Extreme stress testing beyond realistic traffic projections

Won't have, and that is fine:

• Compatibility with browsers your analytics show zero users on (e.g., IE11 in 2026 for a developer tool)
• Extreme localisation for languages your product does not support

Write this prioritisation down. A documented decision not to test something is professional; an undocumented assumption is a risk.

Specifying good NFRs

A well-formed NFR has four components:

1. What — the quality attribute being measured (response time, availability, contrast ratio)
2. Target — the measurable threshold (under 500ms, 99.9% uptime, 4.5:1 contrast)
3. Context — the conditions under which the target must hold (at p95, under 200 concurrent users, for text under 18pt)
4. Environment — where the measurement applies (production, staging with production-equivalent infrastructure)

"The search API [what] must respond in under 300ms [target] at the 95th percentile under 500 concurrent users [context] measured in the production environment [environment]."

That sentence can be turned directly into a k6 test script.

⚠️ Common mistakes

• Treating non-functional testing as a final gate. If the first performance test runs one week before launch and fails, you have no time to fix architecture. Make non-functional testing continuous, not terminal.
• Writing NFRs without business input. "99.999% availability" sounds impressive but costs ten times as much to achieve as "99.9%". Availability targets should reflect what the business actually needs — and is willing to invest in — not what sounds impressive in a spec.
• Automating everything or automating nothing. Some non-functional checks (automated accessibility scans, dependency scanning, lightweight performance checks) belong in CI. Others (full load tests, penetration tests, manual keyboard audits) are too costly to run on every commit. Know which is which.

🎯 Practice task

Take any feature your team is working on, or a feature from a product you know well.

1. Write three NFRs for it — one for performance, one for accessibility, and one for security. Use the four-component format: what, target, context, environment.
2. For each NFR, identify the earliest point in the SDLC where it could be tested. Design? Development? CI? Pre-release?
3. Estimate the relative cost of finding each failure at design time versus at post-launch. The gap between those numbers is the value of planning non-functional testing early.

This exercise turns an abstract principle — "test non-functional early" — into a concrete habit you can apply to any feature ticket.