Branch-Level QA: How We Test Pull Requests Before Code Review

Most teams test after merging. That’s like inspecting a parachute after the jump.

We test every feature branch before it gets near staging. Here’s how our PR-level QA works—and why it stops more bugs than any retroactive regression suite ever will.

What’s Broken in Most Teams

QA only starts after code hits staging
Devs self-declare “ready for QA” with no validation
Broken features collide in shared environments

The result? Late bugs, unstable sprints, and rollbacks dressed as hotfixes.

Why Branch-Level QA Fixes It

Each feature gets its own environment (isolated and temporary)
QA tests while context is fresh
Defects get squashed before code review, not after merge

Branch-level testing turns QA into a preventative measure, not a post-mortem exercise.

PR environments are temporary—once the feature is merged into staging, the PR test link is destroyed. No leftover environments. No contamination.

Our PR Testing Workflow (Start to Staging)

Dev writes code → opens PR
        └─→ CI runs: lint + unit tests
        └─→ AWS deploys PR env: pr-###.feature.app.com

QA receives PR link
        └─→ Manual test + smoke automation
        └─→ Verdict: PASS or FAIL posted to PR

If PASS → Sr Dev review → Merge to staging
Staging sanity → Release tag

Step-by-Step

Pull Request Triggered
- PR created from feature branch
- CI runs: linters, unit tests
- GitHub Actions deploy to AWS test environment
- QA is notified via Slack with the PR test link and Taiga ticket reference
QA Review Begins Immediately
- QA picks up the ticket from Taiga
- Runs manual smoke test + automation suite in PR environment
- Edge-case validation if risk level is high
Verdict Logged and Communicated
- QA changes the status of the Taiga ticket to reflect PASS or FAIL
- Summary of what was tested is added to the ticket
- QA replies to the Slack thread with the verdict to unblock code review
Code Review Comes After QA
- Only passed PRs move to senior developer review
- Reviewed, approved, merged into staging
Staging Is for Sanity, Not Bug Hunting
- QA does a fast integration and regression smoke
- Staging is stable enough to tag a release

Why This Beats Waiting for Staging

🔄 Parallel progress: Devs work on the next ticket while QA tests current one
⏰ Faster feedback: QA doesn’t wait for an environment
❌ Lower failure rate on staging: fewer rollback emergencies
📂 Traceable QA: PR logs show what passed, what didn’t

Want to see the repo that powers this?
📂 Browse the Hybrid QA Docs on GitHub

What to Avoid

“Test later” mindsets — bugs don’t care about your sprint ceremonies
Staging as the first test environment
Slack verdicts with no paper trail

Always test in the branch. Always leave a log in the PR.

Linked Reads

This is how we stop bugs before they start.
No process theater. Just systems that work.