Key takeaways
- A functional requirement says what system does. A non-functional requirement says how well it does it under real conditions.
- Most NFRs fail in testing because they're written as vague expectations ("app should be fast") instead of measurable thresholds ("checkout API responds in under 500ms at p95 under 2,000 concurrent users").
- Mobile apps have NFR categories that web apps don't: battery drain, cold start time, thermal throttling, and behavior under interrupted network.
What an NFR actually is
A functional requirement describes a behavior: "user can log in with email and password." A non-functional requirement describes a constraint on that behavior: "login flow completes in under 3 seconds on a 4G connection."
ISO/IEC 25010:2023, current international standard for software product quality, organizes NFRs across nine quality characteristics: performance efficiency, compatibility, usability, reliability, security, maintainability, portability, functional suitability, and interaction capability.
In practice, most QA teams deal with five of those regularly: performance, security, reliability, usability, and compatibility. The rest show up in enterprise procurement checklists and architecture reviews.
The problem isn't that teams don't know what NFRs are. It's that NFRs are often written too vaguely to test, or they're not written down at all. A product manager assumes the app will be "fast." A developer assumes 2 seconds is fast. A user on a mid-range Android device on 3G considers 2 seconds fast for a loading screen but not for a button tap response. Nobody aligned on number, so nobody tests for it, and disagreement surfaces as a one-star review.
The difference between vague and testable NFRs
This is where most NFR documentation fails. Here's what the difference looks like across common categories.
Performance
Vague: "The app should load quickly." Testable: "The home screen renders within 1.5 seconds on a cold launch, measured on a device with 4GB RAM on a 4G LTE connection."
Reliability
Vague: "The app should be stable." Testable: "The crash rate stays below 0.5% across all sessions over a 7-day rolling window, measured via Crashlytics."
Security
Vague: "User data should be secure." Testable: "All API requests use TLS 1.2+. Auth tokens expire after 30 minutes of inactivity. No PII is written to local device logs."
Usability
Vague: "The app should be easy to use." Testable: "80% of first-time users complete onboarding flow within 90 seconds without tapping help button."
Compatibility
Vague: "The app should work on all devices." Testable: "The app functions correctly on Android 12 through 15 and iOS 16 through 18, covering 92% of active user base."
The pattern is same in every case: a testable NFR has a number, a condition, and a measurement method. If it doesn't have all three, it's a wish, not a requirement.
NFR categories that matter for mobile (and get missed)
Most NFR articles list same categories pulled from ISO standard. Those apply. But mobile apps have additional NFR categories that desktop and web apps don't, and they're ones most teams forget to define until users complain.
App startup time. Cold launch (app not in memory) and warm launch (app was backgrounded) are different measurements. Users notice cold launch times above 2 seconds. Google's Android vitals dashboard flags cold starts above 5 seconds. If your NFR doesn't distinguish between cold and warm, you're measuring wrong thing.
Battery consumption. An app that drains 8% battery in 10 minutes of active use will get uninstalled. This is hard to test on emulators because emulators don't have batteries. You need real device testing to measure actual power draw, and measurement varies by chipset (Snapdragon vs Exynos vs Tensor).
Thermal throttling behavior. When a device overheats, OS throttles CPU and GPU performance. An app that runs at 60fps under normal conditions might drop to 20fps after 5 minutes of heavy use because device got warm. If your app includes maps, video, AR, or continuous GPS, thermal behavior is an NFR you can't ignore.
Network transition handling. A user walks from their office (Wi-Fi) to parking lot (4G) while placing an order. The network switches mid-request. Does app retry? Does it show an error? Does it lose cart contents? This isn't a functional bug. It's a non-functional failure mode that needs a defined expectation and a test.
Behavior under low memory. When the OS kills background processes to free RAM, does your app restore state correctly when the user switches back? On mid-range Android devices with 3-4GB RAM, this happens more often than most teams realize. The NFR should specify: "app restores user's position in current flow after an OS-initiated background kill."
How to test NFRs in practice
Functional tests check if a feature works. NFR tests check if a feature works well enough under specified conditions. The testing approach differs by category.
Performance NFRs need load testing tools (k6, Gatling, Locust for APIs) and device profiling tools (Android Profiler, Xcode Instruments for mobile). You're measuring response times, frame rates, memory usage, and startup times under defined conditions.
Security NFRs need a combination of static analysis (dependency scanning, code review), dynamic testing (penetration testing, API fuzzing), and compliance checks (TLS configuration, data storage policies).
Reliability NFRs need crash monitoring (Crashlytics, Sentry) and long-running test suites that simulate extended usage sessions, background/foreground transitions, and interrupted flows.
Compatibility NFRs need app running on real devices across specified OS and hardware matrix. This is where emulators fall short. An app rendering correctly on an emulator's stock Android 14 doesn't prove it renders correctly on Samsung's One UI 6.1 or Xiaomi's HyperOS.
Drizz covers the compatibility layer. You write test flow once in plain English, and it runs across multiple real devices and OS versions. The Vision AI engine interacts with the screen visually, so the same test validates the same flow on a Pixel 8, a Galaxy S24, and a Redmi Note 13 without separate scripts. If layout breaks on one device but not others, the test catches it because it's looking at what the user actually sees, not what DOM or view hierarchy says.
FAQ
What is an NFR in testing?
A non-functional requirement (NFR) defines how a system should perform, not what it should do. It covers qualities like speed, stability, security, and usability. In testing, NFRs are validated by measuring system against specific thresholds under defined conditions.
What's the difference between functional and non-functional requirements?
Functional requirements describe specific behaviors ("user can reset their password via email"). Non-functional requirements describe constraints on those behaviors ("password reset email arrives within 30 seconds and reset link expires after 15 minutes"). Both need testing, but tools and techniques differ.
How do you write a testable NFR?
Include three elements: a measurable threshold (under 500ms), a condition (under 2,000 concurrent users), and a measurement method (p95 latency measured at load balancer). If an NFR doesn't have a number, a condition, and a way to measure it, it's not testable.
Are NFRs the same as non-functional testing?
Not exactly. NFRs are requirements themselves (what system needs to achieve). Non-functional testing is activity of verifying that system meets those requirements. You can have NFRs without testing them (a gap), and you can do non-functional testing without written NFRs (ad hoc), but ideally two are connected.
Which NFRs are specific to mobile apps?
App startup time (cold vs warm launch), battery consumption, thermal throttling behavior, network transition handling (Wi-Fi to cellular mid-flow), and state restoration after OS-initiated background kills. These don't apply to web or desktop apps and are often missing from NFR documentation even for mobile-first products.
