Press CTRL+K to open search

Overview

  • Published on Aug 26, 2026
  • 4 minute(s) read
  • G
 Prev Next

Testing & QA

QA checklists and automated-test coverage notes for every module we ship to QA.

:::tip Internal-facing
This section is for engineers preparing a module for QA and for QAs running a pre-release pass. It is not user documentation — for user-facing flows, see Modules.
:::

What lives here

  • One checklist per module area (e.g. Monetization → Offers, Monetization → Plans, Customer Support → Refunds).
  • Each checklist groups test cases by severity and, for Critical + High items, maps them to the unit tests that actually cover them today.
  • Each checklist also lists the unit tests worth adding next so the suite can catch the risk going forward.

Why we do it this way

A single document that QA, product and engineering can all read turns "what's been tested?" from a guessing game into a signed-off artifact. It also forces the team to be honest: a Critical item without automation is either a manual-only contract or a gap in the suite.

Available checklists

Module Checklist Status
Content → Core Content Core QA Checklists Active
Content → Secondary Video Asset Secondary Video Asset Functional Parity Active
Monetization → Offers Offers QA Checklist Active
AppCMS → Common AppCMS Common QA Checklist Active
AppCMS → Brand Brand Theme QA Checklist Active
AppCMS → Logo & Images Logo & Images QA Checklist Active
AppCMS → Settings Settings QA Checklist Active
AppCMS → Service Service QA Checklist Active
Customer Support → Chromecast Logs Chromecast Logs Parity Checklist Active

AppCMS network parity is tracked against viewlift-one-prod. Core brand + settings network get/save/publish are at parity; remaining gaps called out in the area checklists (brand version history, settings field gating, admin-network activation controls). Devices/builds are deprecated in cms-v5 (intentional).

When you add a new checklist, add a row here so it's discoverable from one place.

Checklist series in this section

We currently maintain two checklist styles:

  • Core smoke checklists (P0-P3): concise pass/fail release gating for broad feature-path coverage. Entry point: Content Core QA Checklists.
  • Detailed module plans (Critical-Low): deeper scenario-level plans with coverage badges and unit-test mapping.

Severity scale

Severity Definition
Critical Release blocker. Money, data integrity, access control, irreversible actions. A failure here causes direct harm (charges wrong amounts, leaks data, breaks contracts with customers).
High Core happy paths and guard rails. A failure here breaks the feature's primary job for a meaningful chunk of users.
Medium Edge cases and UX quality. A failure here is annoying but has a workaround.
Low Polish, copy, console noise, minor inconsistencies.

Rule of thumb: if in doubt between two levels, pick the higher one the first time and downgrade only with evidence.

Unit-test coverage badges

Critical and High items must carry a coverage badge in their title so QA knows where to lean in on manual testing. We use the built-in VitePress <Badge> component with three statuses:

Badge Meaning
<Badge type="tip" text="covered" /> A unit/integration test asserts the exact behaviour. QA can treat it as a smoke test and focus elsewhere.
<Badge type="warning" text="partial" /> Related assertions exist but do not close the risk end-to-end, or the existing test codifies the current broken state.
<Badge type="danger" text="not implemented" /> No automation yet. QA must test manually. Usually because the underlying code has no contract to assert against.

When marking partial, add a one-line gap note inside the item; when marking not implemented, note whether the fix also needs a new assertion in the Unit tests worth adding next table.

How to add a new checklist

  1. Copy template.md into the appropriate module folder (create subfolders like monetization/, customer-support/ as needed).
  2. Name the file after the module area — e.g. offers.md, refunds.md. Do not prefix with the module name; the folder does that.
  3. Fill in the checklist. For every Critical and High item, map existing tests by their file path and describe / it name (grep src/__tests__/ to find them).
  4. Add a row to the Available checklists table above.
  5. Register the file in docs/.vitepress/sidebar.ts under the Testing & QA block.
  6. Open a PR and tag the module owner + QA lead.

How to update an existing checklist

  • Items are append-only. Adding new items is fine at any time; never renumber existing IDs (QA tickets, spreadsheets, and comments reference them).
  • Flip a coverage tag in the same PR that changes the underlying behaviour or test. A Missing becoming Covered is a satisfying diff.
  • Cross-out an obsolete item by moving it to a small "Retired" section at the bottom of the checklist rather than deleting it, so ticket history remains traceable.

What does not live here

  • User-facing step-by-step guides — those belong in Modules.
  • Architectural reasoning — ADRs and RFCs.
  • Library-level testing docs (e.g. Upload Engine's test surface) — those stay next to the library, like Upload Engine → Testing.
  • Backend or E2E test plans — reference them from the checklist but keep them in their own repo.