---
title: 'What Is Quality Assurance'
source: 'https://academia.sh/en/courses/testing-fundamentals/what-is-quality-assurance'
course: 'Quality and Testing Fundamentals'
language: en
updated: '2026-08-23T14:25:18+00:00'
license: 'CC BY-SA 4.0'
---

# What Is Quality Assurance

The definition of quality as conformance to stated and implied expectations, measuring product quality and process quality separately, and the defect that an unchecked rule hides.

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.

```js
// 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.

```js
// 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.

```js
// 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.

```js
// 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.