Quality Is Everyone's Job, Testing Is a Discipline
What "quality" actually means for software, and how testing — one specific, learnable discipline — supports it without being solely responsible for it.
What you'll learn
- Distinguish software quality from software testing
- Name at least four quality characteristics beyond "it works"
- Explain why testing can show the presence of defects but never their absence
Explanation
A team ships a login form. It logs users in correctly every time. Is it "quality" software?
Maybe not. It might be slow on a phone. It might be unreadable to someone using a screen reader. It might expose a stack trace when the password field is left empty. It might be impossible for a new engineer to safely modify six months from now. Correctness is one quality characteristic among several — functionality, reliability, performance, usability, security, compatibility, and maintainability are all part of the widely used ISO/IEC 25010 model. "It works" only covers the first of these.
Quality is a property of the product, built in by everyone who touches it — the person who writes the requirement, the person who designs the screen, the person who writes the code, and the person who tests it. Testing is one specific discipline within that effort: the deliberate, structured activity of executing a system (or reasoning about it) to find information about its quality, usually by looking for ways it disagrees with what it's supposed to do.
That distinction matters practically. A team that treats "testing" as the only quality activity — write the code, then throw it over a wall to testers — will keep shipping defects that testing catches too late to fix cheaply, because the requirement was already ambiguous or the design already made a state impossible to represent correctly. A team that treats quality as everyone's job, with testing as the specialist activity that provides evidence, catches problems earlier and cheaper.
There's a famous, precise limitation worth internalizing early: testing can show that defects are present. It can never prove that they are absent. Running a hundred passing tests against a function does not prove the function is correct for every possible input — it proves those hundred inputs behaved as expected. This is why test design (choosing which cases actually matter) is the real skill this course teaches, not just running checks.
Example
A simple age-validation function. It "works" for the cases the author thought of — testing exists to find the ones they didn't.
function isAdult(age) {
return age >= 18;
}
console.log(isAdult(25)); // true
console.log(isAdult(10)); // false
console.log(isAdult(18)); // true — but did the author mean 18 or older, or over 18?
// console.log(isAdult(-5)); // negative age: what should happen?
// console.log(isAdult("18")); // a string instead of a number: what happens?Try it yourself
Uncomment each commented line one at a time and press Run. Neither crashes — but do either return the *right* answer for a real system?
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
A product owner says a page must "load quickly and work for everyone." List which ISO 25010-style quality characteristics that sentence actually touches by setting each flag to true or false: touchesPerformance, touchesUsability, touchesFunctionality.
Checks: correctly flags performance · correctly flags usability · correctly flags functionality
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
A bug report says: "The checkout button is on-screen in the correct place, uses correct colors, and the click handler correctly charges the card — but it takes 9 seconds to respond." Set isFunctionalDefect and isPerformanceDefect to reflect which characteristic(s) this report is actually about.
Checks: correctly identifies it is not a functional defect · correctly identifies it is a performance defect
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Treating "testing" and "quality assurance" as synonyms — testing produces evidence about quality; it does not by itself assure quality exists.
- Assuming a passing test suite means the software has no bugs, rather than "no bugs in the cases we thought to check."
- Reducing quality to functional correctness and ignoring performance, usability, security, and maintainability.
Knowledge check
Takeaway
Quality is a broad, shared property of software; testing is the specific, learnable discipline of generating evidence about it — and even a perfect test run is evidence, not proof.
Summary
This lesson separated software quality (a multi-dimensional product property) from software testing (one discipline that investigates it), and introduced the core limitation that testing shows the presence, not the absence, of defects.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.