The simplest way to think about it: functional testing asks "does this feature work?" Non-functional testing asks "does it work fast, securely, and across devices?"
A checkout button that processes payments correctly passes functional testing. That same button taking 8 seconds to respond on a 3G connection, crashing on devices with 3GB RAM, and being invisible to screen readers fails non-functional testing. The feature works. The experience doesn't.
Both categories are necessary. An app that functions correctly but crashes under load, leaks user data, or drains the battery will still lose users. The distinction matters because each category uses different tools, runs at different stages, and catches different classes of bugs.
Functional testing: does it work?
Functional testing validates that the app's features behave according to requirements. You give it an input, it should produce the expected output. Every button, form, flow, and API call does what the spec says.
The subtypes that fall under functional testing:
Unit testing. Test one function or method in isolation. Does calculateTotal(items) return the correct sum? (See our guides to React Native testing and Flutter testing for framework-specific examples.)
Integration testing. Test multiple components connected. Does the checkout API correctly apply a coupon code and return the discounted total?
E2E testing. Test the full user flow through the actual interface. Can a user add an item, apply a coupon, enter payment, and see the order confirmation? This is where cross-screen bugs surface.
Regression testing. Re-run existing functional tests after a code change to confirm nothing broke. The developer fixed the coupon bug. Did the fix break tax calculation?
Smoke testing. A quick, broad check that the build's core functions work. Does the app launch? Can you log in? Does the home screen load?
Sanity testing. A quick, focused check that a specific fix works. The developer patched the payment timeout. Does payment complete now, including edge cases?
Functional testing is where most teams start and where most automation effort goes. It's also where test case templates are most useful, because functional tests have clear inputs, steps, and expected outputs.
Non-functional testing: does it work well?
Non-functional testing validates the qualities of the app that aren't about feature correctness. Speed, stability, security, usability, and compatibility are all non-functional. The feature works. The question is whether it works under real-world conditions.
The subtypes that fall under non-functional testing:
Performance testing. How fast does the app launch? How smooth is the scroll? What happens under a 3G connection? Cold start above 3 seconds loses the user. Crash-free rate below 99% is a retention crisis. Instabug's 2025 data sets 99.95% crash-free as the competitive target.
Security testing. Does the app store payment tokens encrypted? Does the API reject unauthenticated requests? Are session tokens expiring correctly? On mobile, this includes checking whether sensitive data is stored in Android Keystore/iOS Keychain rather than plaintext SharedPreferences.
Usability testing. Can a first-time user complete the core flow without instructions? Are touch targets large enough? Is the navigation intuitive? This is one of the few testing types that should stay manual, because it requires human judgment.
Compatibility testing. Does the app work across Samsung (One UI), Pixel (stock Android), Xiaomi (HyperOS), and iPhone? Does it render correctly on a 720p screen and a 1440p screen? Does it handle Android 13, 14, and 15 simultaneously? On mobile, this is the most device-specific testing type. Emulators miss most compatibility bugs because they run stock Android without OEM skins.
Accessibility testing. Does the app work with screen readers? Are font scaling and color contrast handled? Touch targets at least 44x44px? Over 30% of users aged 45+ use larger font sizes. An "Add to Cart" button that works at default size might truncate to "Add to C..." at 1.3x scaling.
The same checkout flow, tested both ways
Here's the clearest way to see the difference. Same feature, both lenses.
Functional tests on the checkout flow:
Does tapping "Add to Cart" add the item? Does the cart total update correctly? Does applying promo code "SAVE20" reduce the total by 20%? Does entering a valid credit card complete the payment? Does the order confirmation screen show the correct total and items? Does an expired card show an error message?
These tests have binary answers: yes or no. The feature works or it doesn't.
Non-functional tests on the same checkout flow:
How long does the checkout screen take to load on a Samsung Galaxy A14 with 3G? (Performance.) Does the payment token get stored encrypted on the device? (Security.) Can a user with VoiceOver complete the checkout without sighted assistance? (Accessibility.) Does the "Place Order" button stay visible when the keyboard opens on a small screen? (Usability.) Does the checkout work identically on Android 13, 14, and 15? (Compatibility.)
These tests don't have binary answers. They measure degrees: how fast, how secure, how usable, how compatible. The feature works in all cases. The question is whether it works well enough for real users in real conditions.
The comparison table
Why this matters more on mobile
On web, functional and non-functional testing are relatively clean categories. The functional test passes or fails in a browser. The performance test measures load time in that same browser.
On mobile, the two categories bleed into each other because of device fragmentation. A functional test (does the checkout button work?) can fail for non-functional reasons (the button works, but on a Samsung Galaxy A14 with One UI, the keyboard covers it and it's untappable). The feature functions correctly. The device's OEM behavior makes it inaccessible. Is that a functional failure or a non-functional one? In practice, it doesn't matter. It's a bug that blocks the user.
This is why mobile testing strategies need both categories running on real devices, not just emulators. An emulator will pass the functional test (the button works on stock Android). Only a real Samsung device reveals the non-functional failure (the keyboard covers the button on One UI).
Drizz handles the functional layer: plain-English tests ("Tap 'Place Order,' validate 'Order Confirmed' is visible") run on real devices across the OEM matrix. Vision AI finds elements visually instead of using selectors. Self-healing adapts when the UI shifts across devices. The popup agent handles OEM dialogs. Because these functional tests run on real hardware, they also catch non-functional issues like device-specific rendering failures, layout breaks, and OEM-specific behavior that emulators miss.
For the non-functional layer, pair Drizz with performance testing tools (Android Studio Profiler, Xcode Instruments) and analytics/monitoring tools (Crashlytics, Sentry, Instabug) for crash-free rate tracking in production.
For a full breakdown of every testing type under both categories, see our guide to the 10 types of mobile app testing. For a strategy that maps both categories to your sprint cycle, see our test automation strategy guide.
FAQ
What is functional testing?
It validates that the app's features work according to requirements. Input X produces output Y. The checkout button processes payment. The login accepts valid credentials. It asks: "Does this feature do what it's supposed to do?"
What is non-functional testing?
It validates the qualities of the app beyond feature correctness: speed, stability, security, usability, and compatibility. It asks: "Does the feature work fast enough, securely enough, and across enough devices for real users?"
Can a test be both functional and non-functional?
In practice, yes. A functional test running on a real device can catch non-functional issues (layout breaks, OEM-specific rendering) because the device's behavior affects whether the feature is accessible. On mobile, the categories overlap more than on web.
Which should I do first, functional or non-functional testing?
Functional first. There's no point measuring how fast a feature loads if the feature itself is broken. Start with smoke and regression testing, then layer in performance, security, and compatibility before release.
What types of testing fall under functional testing?
Unit testing, integration testing, E2E testing, regression testing, smoke testing, sanity testing, and acceptance testing. Each validates that specific features or flows work correctly.
What types of testing fall under non-functional testing?
Performance testing, security testing, usability testing, compatibility testing, accessibility testing, load testing, stress testing, and endurance testing. Each measures a quality attribute of the app.
