Skip to content

QA SOP

Role: QA Engineer
Prerequisites: Complete the Meta SOP first
Visual reference: Whimsical Flowchart

You are QA developers, not QA testers. You own all bugs and the test suites. Every bug you encounter is yours to resolve — you fix it locally in code, open a PR, and merge it. The backlog shrinks because you fix things, not because you file tickets. You also own the regression test suites — keeping them green, expanding coverage, and making sure they catch real issues.

You are trained to handle bugs across cred-web-commercial and cred-api-commercial. Your skillset will expand over time to cover more of the stack.

Deployment Cadence

Merges to develop stop on Fridays. Monday to Wednesday is your dedicated QA testing window on a stable staging environment. Production deploys on Wednesday after your sign-off. This is your buffer to catch regressions before they hit customers — use it aggressively.

High-Risk PRs Need Your Review

Database migrations, new tables, and other high-risk changes require a manual code review from a senior back-end engineer before merging. You may be asked to test these changes after merge — they are the most likely to cause production issues.

The Bug Fix Loop

(See the Whimsical flowchart for the visual)

1. Bug encountered (existing backlog, triage, product support channels)
    ↓
2. Fix it locally in Cursor
    ↓
3. Open PR
    ↓
4. CI automation handles conflicts and code review
    ↓
5. Passes regression tests + manual verify of fix
    ↓
6. Merge

Daily Rhythm

Your job is to crunch through bugs from every source and add tests so we never see the same bug twice.

1. Crunch the Bug Backlog

Open Linear, filter to the bug backlog. Pull the highest priority unassigned bugs and work through them top to bottom. Don't cherry-pick easy ones — grind through by priority until the backlog is empty.

2. Pick Up From Triage

Check the triage queue for newly reported bugs. Claim them, reproduce them, fix them. If it came from triage, it's already been flagged as a real issue — treat it as high priority.

3. Test Develop

Regularly test the develop branch. Click through flows, try edge cases, break things on purpose. When you find something broken:

  • Fix it immediately if it's quick to diagnose
  • If it needs more investigation: add it to Linear, assign to yourself, fix it in your next dedicated slot
  • If it's clearly a regression from a recent merge: Slack the engineer who merged it with the PR link — then still try to fix it yourself before waiting for them

4. Product Support Bugs

Bugs reported through product support channels are real customer pain. Pick these up with urgency — they represent issues hitting users right now.

5. Test Post-Merge Features

When an engineer flags a complex or risky feature for QA review after merge: test it thoroughly, fix anything you find with Cursor, and only escalate if genuinely stuck.

6. Add Tests for Every Bug You Fix

After fixing a bug, add a test that catches it. Every bug fix should come with a regression test so the same issue never ships again. This is how the test suite grows — driven by real bugs, not hypothetical scenarios.

How to Fix a Bug

Step 1 — Move the Ticket to In Testing

When you pick up a bug, move the Linear ticket to In Testing so the team knows it's being actively worked:

Using the Linear MCP, move [issue ID] to "In Testing" 
and assign it to me.

Step 2 — Reproduce It Reliably

Use the tools you have to find the error yourself before asking anyone:

  1. GCP Cloud Logs via Cursor — this is your fastest path. Ask Cursor to pull the logs for you:
Using the GCP Observability MCP, find error logs related to 
[describe the bug / endpoint / user action] from the last 
[timeframe]. Show me the stack traces and failed requests.

  1. PostHog Session Replay — find the user's session, watch the replay, see exactly what happened and where it broke

  2. Last resort — ask the customer. Only if logs and replays give you nothing. Keep it short: ask for the exact steps they took and any error they saw.

If you still can't reproduce the bug consistently after all three, add it to Linear with the reproduction steps you've tried and what you found in logs/replays. Move on. An unreproducible bug can't be fixed.

Step 3 — Diagnose and Fix with Cursor

Open Cursor with all five repos in your workspace:

Plan a fix for a bug in [area of the app / repo name].

What happens: [describe the behaviour you see]
What should happen: [describe the expected behaviour]
Error / console output: [paste anything relevant]

Diagnose the root cause and show me the plan before writing any code.

Review the plan, then tell Cursor to implement it. Read and understand what it changed — you need to be able to explain it in the PR description.

Step 4 — Branch Off Develop

git checkout develop
git pull
git checkout -b fix/[brief-description]

Step 5 — Apply and Test the Fix

  1. Apply Cursor's fix
  2. Reproduce the original bug — confirm it's gone
  3. Check nothing adjacent is broken (click around the area of the fix)
  4. Check loading, empty, and error states if relevant

Step 6 — Open a PR

Bugs should be automatically fixed and a PR opened. The standard is: pull the code, fix it locally, verify it, and open the PR — all in one flow.

  • Title: [Fix] [brief description of what was broken]
  • Description: what was broken, what caused it, what the fix does — three sentences max

Step 7 — Merge

  1. Wait for regression tests to pass (Rainforest QA green, no use client errors)
  2. Manually verify the fix — reproduce the original bug and confirm it's gone
  3. Merge it yourself — QA merges their own bug fixes, no review required unless the fix is large or touches core architecture

When You Can't Solve It

If you've genuinely spent time with Cursor and are still stuck:

The test: Have you given Cursor the error, the reproduction steps, and the relevant code and asked it to diagnose and fix? If not — do that first. If yes and you're still blocked — escalate.

  1. Slack the relevant developer — share your PR (even if incomplete) so they can see what you've tried
  2. Create a Linear ticket for the developer with the relevant priority:
Using the Linear MCP, create a bug ticket for [description].

Include: reproduction steps, what I tried, where I got stuck, 
relevant error/console output, and link to my PR: [PR URL].
Assign to [developer name] with [priority level] priority.
  1. Move on — there are other bugs to fix

What QA Does Not Do

  • Does not write bug reports and wait. If you find it, you fix it.
  • Does not accept "needs a developer" without trying Cursor first. Cursor can fix most things. Try it.
  • Does not do net-new feature development. That's Engineering.
  • Does not leave a bug unlogged. If you can't fix it immediately, it goes into Linear before you move on.

Troubleshooting

Problem Fix
Can't reproduce the bug Log it in Linear with what you tried. Move on.
Cursor can't find the root cause Give it more context: the specific component name, the network request that's failing, the exact error from the console.
Fix works locally but breaks something else Ask Cursor: "My fix for [X] is causing [Y] to break. What's the conflict and how do I resolve it without breaking either?"
Branch has conflicts Ask Cursor: "Fix these merge conflicts." Never edit manually.
Rainforest QA failing on your fix PR Paste the failure output into Cursor. Ask it to fix the failing test or the code causing it. Do not merge with a failing test.
Genuinely need a developer Write up what you tried in Linear, assign to the relevant dev, move on.