Functional vs Non-Functional Testing

"Does the promo code apply the discount?" and "does the search page load in under two seconds?" are both testing — but they aim at fundamentally different things. The first checks what the system does; the second checks how well it does it. The industry splits all testing along this line — functional versus non-functional — and the split organizes job ads, test plans, and the second half of this book.

An apartment viewing makes the line intuitive. That the apartment has two rooms, a kitchen, and a working front-door lock — those are functions; they exist or they don't. Whether the heating keeps you warm in February, the walls block the neighbor's drums, and the hot water survives two showers — those are qualities. You'd never sign a lease after checking only the room count. Users judge software exactly the same way; they just do it without words.

Functional Testing: What It Does

Functional testing checks behavior against requirements: features, rules, calculations. Apply SUMMER15 to a 4-night stay — does the total drop 15%? Cancel 50 hours before check-in — is it free? Everything you've tested in this book so far has been functional, and most of Chapters 4 through 8 stays in this territory, because functional behavior is where test design techniques bite hardest. The defining property: each check traces to a rule about what the system should do, and passes or fails against it.

Non-Functional Testing: How Well

Non-functional testing checks the qualities — the industry affectionately calls them the -ilities. How fast (performance)? How safe against attackers (security)? How usable by everyone, including people with disabilities (usability and accessibility)? Does it work across browsers and devices (compatibility)? Does it stay up (reliability)? A name that misleads every beginner exactly once: non-functional does not mean "the feature doesn't work." It means the check targets a quality attribute instead of a function. The name is unfortunate; the industry is stuck with it; now you're immune.

Why Non-Functional Bugs Hurt Differently

Here's what makes the qualities dangerous: their failures rarely arrive as bug reports. A traveler who hits a broken promo code writes to support. A traveler who finds search sluggish just... leaves — and books with a competitor whose search doesn't make them wait. Slow, confusing, or insecure products bleed users silently, with nothing in the tracker to show for it. Which means nobody is coming to tell you about non-functional problems; noticing them is part of the tester's job description, even when every functional check is green.

Fernway ran this experiment for you. Search returns perfectly correct results — functional: pass. On a mid-range phone, it takes nine seconds — and traveler session recordings show most people give up at four. Every requirement Petra wrote was met, because every requirement Petra wrote was functional. The nine seconds violated a requirement nobody had written down.

Non-Functional Requirements Exist Too

That's the fix, and it's yours to trigger: qualities can be written as requirements with yes-or-no answers, exactly like Chapter 2 taught. "Search results appear within 2 seconds on a typical mobile connection" is as testable as any acceptance criterion — someone just has to bother writing it. On real teams, the person who notices the missing quality requirement is very often the tester, and the noticing happens in refinement: "the story says search returns matching properties — is there a speed expectation?" One sentence, and the nine-second surprise becomes impossible.

So after the Fernway incident, you get "within 2 seconds" added to the search story. The quality now has a number, the number has a test, and the test has an owner. That's the whole pattern: unwritten qualities become written requirements, and written requirements become testable.

Where This Book Covers the Qualities

One honest map, so you know what's coming. Functional testing dominates Chapters 4 through 8 — the techniques, the documentation, the process. The non-functional families each get a proper conceptual treatment in Chapter 10: performance (including what "load testing" means when the summer sale hits), security through a QA lens, usability and accessibility, and mobile's special physics. They're specialist fields — deep careers exist inside each — but every QA engineer is expected to converse in all of them, spot their missing requirements, and know when to call the specialist. That conversational fluency is exactly what Chapter 10 builds.