Code Review & PR Workflow for QA

The Pull Request is the one place where testing happens before the bug reaches a build. This module gets you into that conversation with something useful to say.

Why This Module Matters

Most teams treat code review as a developers-only ritual. That is a waste of the person best placed to spot a missing negative case, an untested boundary or a silently swallowed error.

A Pull Request is a proposal: here is a branch, please look at it before it becomes part of main. Everything you need is attached — the full diff, the branch name, the CI results, and a thread where comments live next to the exact lines they concern. And crucially, the branch is on the server, which means you can pull it onto your own machine and run it before anyone merges anything.

That last step is where QA earns its place in review. "The diff looks fine" is worth little. "I checked out the branch, ran the suite, and the password reset flow throws on an expired token" is worth a great deal.

What You'll Learn

• The life cycle of a Pull Request: open, review, change, approve, merge, close
• git fetch origin — downloading new branches and updates without merging anything
• The difference between origin/feature-x (a remote-tracking branch) and your local copy
• Checking out a developer's PR branch to run it locally, and cleaning up afterwards
• Writing review comments that are specific, reproducible and easy to act on
• Where a QA comment belongs on the diff, and when it belongs in a bug report instead

Pro Tip

Fetch is always safe. git fetch changes nothing in your working directory and touches none of your branches — it only updates your picture of the server. When in doubt, fetch first and decide afterwards.