Skip to main content

QA Process

How a ticket moves from development into QA and out to Done, what must be on the ticket before QA touches it, and where the line sits between automated coverage and human verification.

Ticket lifecycle​

Every ticket follows the same status flow:

In Progress → In Review → QA/Testing → Done

  • In Progress — the engineer is building. Tests are written alongside the feature, not after it.
  • In Review — code review on the diff. The commit history links back to the ticket, so the ticket's development panel shows exactly which commits and branches carry the change.
  • QA/Testing — the change is deployed to the dev environment and ready for verification. This is where QA picks it up.
  • Done — verified per the ticket's test instructions, with automated coverage in place.

A ticket should never arrive in QA/Testing without the two things below: deployed code on dev, and test instructions on the ticket.

Test instructions are mandatory​

Before any ticket is handed to QA, the engineer writes step-by-step test instructions in the ticket description. A ticket without them goes back. The required format:

What every set of instructions contains​

  1. Numbered steps — one action per step, in order.
  2. Exact inputs and selections — the precise values to enter, options to pick, files to upload. "Fill in the form" is not a step; "Select role Backend Engineer, interview type Technical – Theoretical" is.
  3. ✅ Expected result per step — each step states what you should observe when it passes, so a failure is attributable to a specific step.
  4. Regression sections — the adjacent flows that must still work after this change (e.g. "the coding interview type is unaffected — run one and confirm the editor still appears").
  5. Rollback levers — what to flip or revert if the change misbehaves (feature flag, config value, prior version), so QA can report not just "broken" but "broken, and here is the mitigation".
  6. The concrete URL/environment to test on — instructions name where to run them: local (localhost:3000), the dev site (https://develop.theinterviews.ai), or production (https://www.theinterviews.ai). Interview-room flows may also reference the session room (<SESSION_ROOM_URL> — ask a teammate).

Automated vs human testing​

The default proof of done is green automation, not a manual pass.

What ships with every feature​

  • Unit/integration tests in the owning repo — green before the change is committed. Coverage targets the highest meaningful level, not a vanity percentage.
  • A Playwright browser E2E spec for user-facing flows, added to the E2E suite and runnable against the dev build — so every shipped behavior has automated regression going forward. See E2E Suite.

Where humans test​

Human testing is reserved for the critical, irreversible paths — the places where a miss is unrecoverable:

  • Live interview entry — a candidate joining a real voice interview.
  • Billing — anything touching charges, plans, or entitlements.
  • Auth — login, signup, session handling.

Everything else is automated. Routine work is not gated on manual QA.

What QA verifies vs what automation already proved​

When a ticket reaches QA/Testing, automation has already proved:

  • The logic works at the unit/integration level (green in the owning repo's suite).
  • The user-facing flow completes in a browser (Playwright spec against the dev build).
  • Lint, types, and build all pass (CI gates the merge).

QA's job is what automation cannot judge:

  • Following the ticket's test instructions end-to-end on the named environment — confirming the real deployed behavior matches each ✅ expected result.
  • Experience quality — does the flow make sense from the candidate's or recruiter's chair? Automation asserts elements exist; it doesn't notice a confusing state or an awkward transition.
  • The critical-path human checks — live interview entry, billing, and auth flows where listed in the instructions.
  • Regression sections — the adjacent flows the instructions call out.
  • Filing findings — anything off-script becomes a new ticket, not a silent note.

If QA passes, the ticket moves to Done. If it fails, it goes back to In Progress with the failing step number and observed behavior.