Learning Objectives
By the end of this lesson, you'll be able to:
- 🎯 Define non-functional testing and distinguish it from functional testing
- ⚡ Explain the main types: performance, security, usability, accessibility
- 🐛 Make the case that "works but slowly" is a legitimate bug
- 👥 Know which types of non-functional testing are typically done by QA vs. specialists
The Big Idea
"It works."
Two of the most dangerous words in software development — because they answer only one question.
Does it work fast enough? Does it work securely? Does it work for everyone? Can a blind user operate it? Can it handle 10,000 users at once?
Non-functional testing answers the HOW — not the WHAT. It measures quality attributes, not functional behavior.
And yes: a feature that works but takes 45 seconds to load is a bug. 🐌
What Is Non-functional Testing?
Non-functional testing verifies quality attributes of a system — how well it performs, how secure it is, how usable it is — rather than whether specific functions work.
These are sometimes called the "ilities":
- Performance → Speed, responsiveness, stability
- Reliability → Does it work consistently, without random failures?
- Usability → Can a real human figure it out without instructions?
- Security → Can it be exploited? Are user data and sessions protected?
- Scalability → Does it work under 10 users? What about 10,000?
- Accessibility → Can people with disabilities use it? (Screen readers, keyboard navigation, color contrast)
- Compatibility → Does it work on Chrome, Firefox, Safari, iOS, Android?
Performance Testing
What it checks: How fast and stable is the system under various load conditions?
Key subtypes:
| Type | What it tests |
|---|---|
| Load testing | How does the system behave under expected normal load? |
| Stress testing | What happens when load exceeds normal? Where does it break? |
| Spike testing | How does it handle a sudden sharp increase in traffic? |
Why it matters: A feature that works perfectly with 1 user can become unusable with 1,000 simultaneous users. Checkout flows, login pages, and search are the highest-risk areas.
Who does it: Specialized performance engineers, or QA engineers with performance testing tools (JMeter, k6, Gatling). Manual QA contributes by identifying performance expectations in requirements.
Security Testing
What it checks: Can the system be exploited? Are user data and systems protected?
Key areas:
- Input validation — Does the app reject SQL injection, XSS, and malformed data?
- Authentication — Are session tokens secure? Is brute-force protection in place?
- Authorization — Can a regular user access admin-only functions?
- Data exposure — Are passwords stored hashed? Are sensitive fields masked in logs?
Why it matters: A security vulnerability can expose thousands of users' data, cause legal liability, and destroy trust overnight.
Who does it: Security specialists for deep penetration testing. QA engineers for baseline security checks: testing that unauthorized access is blocked, that error messages don't reveal internal details.
Usability Testing
What it checks: Can real users accomplish their goals without confusion, frustration, or needing to read a manual?
Key questions:
- Is the navigation intuitive?
- Are error messages helpful and actionable?
- Is the flow logical from the user's perspective?
- Do empty states give users direction?
Why it matters: A feature that works but confuses users leads to support tickets, churn, and bad reviews. Usability is a product quality attribute, not just a nice-to-have.
Accessibility Testing
What it checks: Can people with disabilities use the product?
Key standards: WCAG 2.1 (Web Content Accessibility Guidelines)
Basic checks every QA can do:
- ✅ Can you navigate the entire page using only the keyboard (Tab, Enter, Arrow keys)?
- ✅ Do images have
alttext? - ✅ Is color contrast ratio sufficient (not light gray text on white background)?
- ✅ Do form fields have labels?
- ✅ Does a screen reader read the page in a logical order?
Why it matters: Accessibility is often legally required (ADA, EAA). It's also good product design — accessible products are easier to use for everyone.
Is "Slow But Working" a Bug?
Yes.
A user who gets the correct result after 45 seconds of waiting has a degraded experience. If the requirement says "search results shall display within 2 seconds" and they're displaying in 45 seconds, that's a functional requirement violation.
Even without an explicit performance requirement: if a feature's response time visibly degrades the user experience, it should be logged as a defect. The severity depends on context — a 45-second page load in a real-time trading app is critical; in a one-time report generator, it might be acceptable.
Pro Tips
💡 Manual QA's role in non-functional testing is awareness, not execution. You don't need to run JMeter to be a good manual QA. But you should know when to raise a flag: "This search is noticeably slow — has performance been tested?"
💡 Include non-functional requirements in your test planning. If the spec mentions "page load under 3 seconds" or "WCAG AA compliance," these are testable requirements — they belong in your test cases.
💡 Accessibility testing catches usability bugs for everyone. A keyboard-navigable interface benefits users with motor disabilities AND power users who prefer keyboard shortcuts. Accessible design is often just better design.
Summary
- 🔍 Non-functional testing = the HOW, not the WHAT — quality attributes, not behavior
- ⚡ Key types: performance, security, usability, accessibility, reliability, scalability, compatibility
- 🐛 Slow, insecure, or inaccessible features are bugs, not just "areas for improvement"
- 👥 QA's role: awareness and baseline checks — specialists handle deep testing
- 📋 Non-functional requirements are testable requirements — include them in your test plan
Up next: Lesson 3.3 — UI/UX Testing: where we focus specifically on how things look and how they feel to navigate. 🎨