What QA Owns After Deploy

This post is part of the CI/CD Quality series. If you missed the previous post, read Part 7 — Risk-Based Regression first.

---

Introduction — The Pipeline Went Green and the User Did Not

The deploy finished. The dashboards are up. Someone asks whether QA is done. The honest answer is a list: which journeys you will prove in production, who watches them for the first hour, and what you will add to the suite if they fail.

This is not an on-call rotation for CPU. It is the slice of production that is still a test.

The Journeys That Run After Release

Take the pull-request bucket from part 7. Pick the three to five journeys that move money, identity, or data the user cannot recreate. Run them as synthetics against production, on a schedule of minutes, with a dedicated account and data you are allowed to create.

# A production smoke, not the whole suite
- name: Synthetic checkout
  run: npx playwright test --grep @synthetic
  env:
    BASE_URL: https://app.example.com
    SYNTHETIC_USER: ${{ secrets.SYNTHETIC_USER }}

A synthetic that uses a real customer’s account will page you for their password change. A synthetic that creates an order must use a payment stand-in or an order you can void. Write that constraint next to the job.

If you cannot run the journey in production at all, say so. A smoke against staging after the artifact is built is the fallback. Call it staging. Do not call it production.

The First Hour

For a release that changes one of those journeys, a person watches the first hour. The person can be QA. The questions are fixed:

• Did the synthetic stay green for three intervals?
• Did the error rate on that route move, compared with the hour before?
• Did support or the log of failed checkouts move?

You need someone who can read those three. You do not need QA to acknowledge every alert in the building. Agree the route names with the people who own the graphs before release day, not during it.

Stop, or Keep Going

Write the stop rule in one sentence. Example: “If the synthetic checkout fails twice, or failed payments on /pay double, halt the rollout.” A rule that says “use judgment” is how a bad release continues while people discuss it.

Halting means the flag goes off or the previous artifact returns. QA does not invent that mechanism on the day. Part 6 of this series already put the flag and the canary in the pipeline. This part is the decision to use them.

After the Hour

If the release hurt users, add one test that would have failed before deploy. Put it in the pull-request bucket if it is fast and stable. Put it in nightly if it is not. A retro item that says “more testing” is not that test.

If the synthetic failed because production data is shaped differently from staging, fix the synthetic’s data. Do not delete it to make the channel quiet.

Conclusion

QA after deploy owns a handful of journeys, the first hour of a risky release, and the test that gets added when the hour goes badly. The rest of production monitoring stays with the people who can act on a host, a queue, or a database.

Action for this week: Name three production journeys. Mark one existing test @synthetic and point it at a safe account. Write the one-sentence stop rule next to the deploy job.

---

This concludes the CI/CD Quality series.