Test case format

Every QC test case on the platform follows the same five-field structure: ID, preconditions, steps, expected, severity. Consistency is the discipline that lets regression suites be readable, diffable, and stable across releases. A test case that doesn’t fit this shape isn’t a test case — it’s a note.

The five fields

ID

Unique stable identifier. Format: <MODULE>-<LAYER>-<NNN>. Example: CAL-FUNC-014 = Calendar / functional / case 14. IDs are immutable once published — a deprecated case keeps its ID and is marked DEPRECATED rather than deleted.

Preconditions

The state that must exist before the test starts. Examples: "user signed in as founder", "at least 3 verified events exist with country=EG", "viewport=mobile". Preconditions never include side effects — they’re assertions about starting state.

Steps

An ordered list of actions, each one observable from the outside. "Navigate to /calendar/events" is a step; "the page renders" is not. Steps are written as imperatives, not as descriptions. Every step is independently verifiable.

Expected

The single condition that, if true after running the steps, makes the test PASS. Compound expecteds ("A and B and C") split into separate test cases. Expected is observable — it asserts what the user/system sees, not internal state.

Severity

4 levels: blocker (release-stopping), critical (must-fix this sprint), major (should-fix), minor (polish). Used for triage when a test fails — blocker fails revert the build automatically; minor fails are catalogued but don’t hold the train.

Worked example

ID: CAL-FUNC-014 · Severity: blocker · Preconditions: at least one CalendarEvent with status='closing-soon' exists in mock-calendar-events; viewport=desktop · Steps: (1) Navigate to /en/calendar (2) Locate the "Closing soon" rail · Expected: the rail renders at least one event card with a warning-tinted "closing soon" badge and a deadline chip showing the days remaining.