What Is Quality Assurance

A program can be running and still be wrong. It can pass its tests and still do something nobody wanted. It can work correctly and still be unusable because it takes ten seconds to respond. What these three sentences share is that the word “working” carries no judgment by itself. This curriculum builds that judgment: how do you decide that a piece of software is the thing that was wanted, and what evidence does that decision rest on?

The Testing and Monitoring topic in the Frontend Quality course introduced unit, component, integration, and end-to-end tests in the browser context. There, testing was a quality tool for one particular domain — the interface running in the browser. Here the topic reverses: the discipline of testing itself is treated independently of any domain. Examples are written with tools set up in the JavaScript and TypeScript course and the Node.js Runtime course, but the questions do not depend on language or platform.

Quality Is a Judgment of Conformance

Quality is the degree to which a product satisfies its stated and implied expectations. Both halves of this definition are required.

A stated expectation is written down: “student members borrow a book for 28 days.” An implied expectation is not written down, but everyone notices when it is violated: a member’s debt should not be visible to another member, a return should not be processed twice, a page should not take minutes to load. However carefully the specification is written, it never covers every implied expectation.

Quality is therefore not an absolute property but a judgment of conformance: it cannot be measured until the question “conformance to what” has an answer. The domain used throughout the course is a small lending library. This domain is the same one used in the Backend Development curriculum’s library system; no code from that system is assumed here — the rules are built from scratch, and the same library is developed across the lessons.

// library.mjs — loan rules
export const RULES = {
  student: { loanDays: 28, maxLoans: 10 },
  member: { loanDays: 14, maxLoans: 5 },
};

export function loanPeriod(memberType) {
  const rule = RULES[memberType];
  if (rule === undefined) throw new Error(`unknown member type: ${memberType}`);
  return rule.loanDays;
}

export function maxLoans(memberType) {
  return RULES[memberType]?.maxLoans ?? 5;
}

export function dueDate(checkoutDay, memberType) {
  return checkoutDay + loanPeriod(memberType);
}

Dates are represented as day numbers: dueDate(1000, 'member') says that a book checked out on day one thousand is due back on day one thousand and fourteen. Calendar arithmetic and time zone issues are not the subject of this quality discussion; a fixed day counter keeps the examples deterministic.

Product Quality and Process Quality

Product quality is a property of the thing in hand: does the library apply its rules correctly, is it fast, is it secure? Process quality is a property of the way of working that produced that thing: is every rule tied to a check, are changes reviewed, are defects recorded along with where they came from?

The link between them is one-directional and probabilistic. A good process does not guarantee a good product, but a bad process makes a good product unrepeatable: one release turns out well, the next does not, and there is no way to know where the difference came from. This is precisely what quality assurance is concerned with.

Measuring the two properties separately first requires a machine-readable list of the rules.

// specification.mjs — machine-readable list of the written rules
export const SPECIFICATION = [
  { id: 'K1', text: 'Student loan period is 28 days' },
  { id: 'K2', text: 'Member loan period is 14 days' },
  { id: 'K3', text: 'A student may borrow at most 10 books' },
  { id: 'K4', text: 'A member may borrow at most 5 books' },
  { id: 'K5', text: 'An unknown member type is rejected' },
  { id: 'K6', text: 'The due date is the checkout day plus the loan period' },
];

Separating the Two Measurements

Product quality measurement answers the question “how many of the written checks pass?” Process quality measurement asks an entirely different question: “how many of the rules in the specification have a check?” The second question is called traceability, and its answer looks not at the product itself but at the link between the product and the specification.

// check.mjs — two separate measurements: product quality and process quality
import assert from 'node:assert/strict';
import { SPECIFICATION } from './specification.mjs';
import { loanPeriod, maxLoans, dueDate } from './library.mjs';

const CHECKS = {
  K1: () => assert.equal(loanPeriod('student'), 28),
  K2: () => assert.equal(loanPeriod('member'), 14),
  K3: () => assert.equal(maxLoans('student'), 10),
  K6: () => assert.equal(dueDate(1000, 'member'), 1014),
};

let passed = 0;
const failed = [];
for (const [id, check] of Object.entries(CHECKS)) {
  try {
    check();
    passed += 1;
  } catch {
    failed.push(id);
  }
}

const unchecked = SPECIFICATION.filter((k) => CHECKS[k.id] === undefined).map((k) => k.id);

console.log(`product quality: ${passed}/${passed + failed.length} checks passed`);
console.log(`process quality: ${SPECIFICATION.length - unchecked.length} of ${SPECIFICATION.length} rules checked`);
console.log(`unchecked rules: ${unchecked.join(', ')}`);

product quality: 4/4 checks passed
process quality: 4 of 6 rules checked
unchecked rules: K4, K5

The first line looks flawless. The second line says what the first line does not cover. Product quality measurement only reports on questions that were asked; questions that were never asked do not appear inside that measurement. Process quality measurement names exactly that gap.

The Cost of a Rule Left Unchecked

What happens once the two missing checks are written becomes visible.

// check-full.mjs — both previously unchecked rules are now written
import assert from 'node:assert/strict';
import { loanPeriod, maxLoans, dueDate } from './library.mjs';

const CHECKS = {
  K1: () => assert.equal(loanPeriod('student'), 28),
  K2: () => assert.equal(loanPeriod('member'), 14),
  K3: () => assert.equal(maxLoans('student'), 10),
  K4: () => assert.equal(maxLoans('member'), 5),
  K5: () => {
    assert.throws(() => loanPeriod('guest'));
    assert.throws(() => maxLoans('guest'));
  },
  K6: () => assert.equal(dueDate(1000, 'member'), 1014),
};

for (const [id, check] of Object.entries(CHECKS)) {
  try {
    check();
    console.log(`${id} passed`);
  } catch (error) {
    console.log(`${id} failed: ${error.message.split('\n')[0]}`);
  }
}

K1 passed
K2 passed
K3 passed
K4 passed
K5 failed: Missing expected exception.
K6 passed

The defect is in the maxLoans function: instead of raising an error for an unknown member type, it silently returns five. An unregistered person can borrow a book, and the system mistakes it for member behavior. The defect was always there; product quality measurement could not see it, because no one had asked that question.

The lesson here is more general than the fact that the fourth line failed. Product measurement only speaks within its own scope; what tells you where that scope ends is process measurement. The sentence “all tests pass” is not a quality claim unless you know which questions were never asked.

Assurance, Control, and Testing

The three terms are often used interchangeably; their scopes differ.

Quality assurance is process-oriented and preventive. Having rules in writing, tying every rule to a check, reviewing changes, and recording defects all fall under this heading. Its question is: what prevents a defect from arising?

Quality control is product-oriented and detective. It looks at whether the release in hand meets expectations. Its question is: does this release have a defect?

Testing is the primary method of quality control, but not the only one. Review, formal analysis, and static inspection also find defects. Testing is distinguished by producing evidence by running the program: it compares observed behavior against expected behavior.

The relationship among the three is hierarchical: testing is a tool of quality control; quality control is a part of quality assurance. This course is primarily about testing, but the question of what testing can and cannot prove is answered at the assurance level.

What testing cannot prove also has a name: a test can only show the presence of a defect, not its absence. A finite set of inputs cannot exhaust an infinite input space. Testing’s job is therefore not “proving flawlessness” but “choosing the inputs most likely to find a defect.” Every technique in test design is an answer to this selection problem.

Summary

• Quality is the degree of conformance to stated and implied expectations; it cannot be measured until the question of conformance to what is answered.
• Product quality is a property of the thing in hand, process quality of the way of working that produced it; a good process does not guarantee a good product, but a bad process makes a good product unrepeatable.
• Traceability measurement asks “how many of the rules have a check”; product measurement only reports on questions that were asked.
• In the example, all four written checks passed; once one of the two unchecked rules was written, a defect surfaced in which an unknown member type was silently accepted.
• Quality assurance is preventive and process-oriented, quality control is detective and product-oriented; testing is quality control’s method of producing evidence by running the program.
• Testing can show the presence of a defect, not its absence.

Next Step

In this lesson, the checks were derived from the specification: whatever the written rule said, the check asked exactly that. This is the question “does the library conform to the specification?” But what if the specification itself is wrong? The rules can be fully implemented, every check can be green, and the result can still be wrong — because the written rule is not the rule the library actually needs to enforce. The next lesson separates these two questions: building it right and building the right thing.