Git & GitHub for Testers
Modern QA teams review code changes before testing them. Git is how you see what changed, check out the right branch, and understand the developer’s intent before you write a single test case.
1 The Hook
A junior tester at a Wellington SaaS company is asked to test a bug fix in the login flow. The developer says “it’s on the feature/login-fix branch.” The tester tests on main — the branch with the old, unfixed code. He can’t reproduce the fix, files a new bug. The developer is confused. Twenty minutes of back-and-forth reveals the problem: the tester didn’t know how to switch branches.
The fix was there all along. Understanding git checkout would have saved 20 minutes and an awkward conversation.
Senior engineer insight
The moment I stopped thinking of Git as a developer tool and started treating git log --oneline as my pre-test ritual, my defect reports became sharper overnight. On one Wellington fintech project we had three feature branches all touching the same payment-processing module simultaneously — knowing which commits were on which branch let me scope my regression testing precisely instead of retesting the entire checkout flow every sprint. The thing that changed how I think about this: a diff tells you the developer's intent, and intent is the best test oracle you have access to before you touch the app.
Most common mistake: Junior testers check out the right branch but forget to run git pull, so they're testing yesterday's version of the fix while the developer has already pushed three more commits.
From the field
A mid-size Auckland e-commerce team ran two-week sprints with every bug fix going through a GitHub PR and a mandatory QA sign-off before merge. The assumption was that QA would just test the deployed staging environment — nobody had told the testers to read the PR diff first. Halfway through a release cycle, a tester approved a fix for a cart-total rounding bug, the PR merged, and the bug reappeared in prod two days later. Post-mortem revealed the fix had been reverted in a later commit on the same branch and the diff would have shown it clearly. After that, the team made PR diff review a mandatory step in the QA checklist — testers were required to comment on the PR in GitHub before moving a ticket to "Testing". Within one sprint, two more near-misses were caught at the diff stage before anyone clicked a single button in the app. The lesson: reading the diff is not a developer skill, it is a QA risk-assessment skill.
2 The Rule
Always confirm which branch you’re testing before you start. The code on main is not necessarily the code the developer wants you to test.
3 The Analogy
Parallel universes.
Git branches are like parallel universes. The main universe is production code. The feature/login-fix universe is the developer’s experimental version with the fix applied.
You need to physically step into the right universe before you can test it. git checkout is the portal. If you test from main while the developer is on the feature branch, you’re literally testing different code — different reality. No wonder you can’t reproduce the fix.
4 Watch Me Do It — The 5 Commands Every Tester Needs
# 1. See what branch you're on and what's changed git status # 2. Download the latest code from the team's repository git pull # 3. See all available branches git branch -a # 4. Switch to the branch you need to test git checkout feature/login-fix # 5. Read what changed in the last few commits git log --oneline -5
That’s it. Five commands. Memorise them and you can navigate any NZ dev team’s repository.
Reading a PR diff in GitHub:
- Red lines (−) = code that was removed
- Green lines (+) = code that was added
- The file path at the top of each diff block = where the change lives
What to look for in a PR review before testing:
| Look at | Ask yourself |
|---|---|
| Which files changed | What areas of the app should I test? |
| Whether test files changed | Did the developer test this themselves? |
| Any TODO or FIXME comments in the diff | Is there known incomplete work? (red flag) |
| Whether the PR description matches the diff | Did the developer deliver what they said they would? |
5 When to Use It
Always do this before testing:
- Run
git statusto confirm which branch you’re on - Run
git pullto make sure you have the latest code on that branch - Read the PR description and diff before clicking anything in the app
Use PR review to:
- Understand the scope of the change before you test (which parts of the app are affected)
- Verify that a bug fix in a test environment is on the right branch
- Catch discrepancies between what the PR says it does and what the diff actually shows
6 Common Mistakes
🚫 Testing on main and trusting the developer deployed their changes
I used to think: if the developer says it’s fixed, I can just test on main or staging.
Actually: feature branches exist precisely because changes aren’t on main yet. Always switch to the correct branch or confirm the deployed environment matches the branch before you start testing. “The fix is on the feature branch” and “the fix is deployed to staging” are different statements.
🚫 Reading code diffs requires programming knowledge
I used to think: I need to understand the code to get anything out of a diff.
Actually: you don’t need to understand the code to get real value. You can see which files changed (scope of impact), how many lines changed (rough complexity), whether test files are included (developer confidence), and whether the change matches the ticket description. That’s useful before you write a single test case.
🚫 Git is only for developers
I used to think: Git is a developer tool, I’ll just wait for QA deployments.
Actually: NZ tech teams increasingly treat PR review as part of the Definition of Done. QA participation — reading the diff, commenting on risks, verifying the branch — is expected before a PR merges in many modern teams. Testers who understand Git are significantly more effective in sprint-based teams.
7 Now You Try
A developer raises a PR to fix a bug where the search filter wasn’t persisting after page navigation. The diff shows changes to 3 files: SearchFilters.tsx, useSearchState.ts, and App.test.tsx.
Based on this information alone — no actual code, just the file names and the bug description — write 5 test cases you would run to verify the fix works correctly and hasn’t introduced regressions. For each test case describe: what you test and what the expected result is.
Why teams fail here
- Testers test on
mainby default because no one explicitly told them branching is part of the QA workflow — this is a process gap, not a knowledge gap, and it belongs in the team's Definition of Ready. - The PR is merged before QA has finished testing because the team doesn't have a branch-protection rule requiring a QA-approved review — testers end up chasing a moving target on main.
- Testers skip the diff and rely entirely on the developer's PR description, which may omit incidental changes to shared components that introduce subtle regressions elsewhere in the app.
- Nobody runs
git pullafter checking out the branch, so two team members end up testing different commits and file contradictory defect reports against the same ticket.
Key takeaway
Your test cases are only as trustworthy as the branch you ran them on — confirm the branch, pull the latest, read the diff, then test.
8 Self-Check
Click each question to reveal the answer.
Q1: You’re asked to test a bug fix. The developer says it’s on feature/BUG-4421. What is the first command you run?
git status to see which branch you’re currently on. Then git checkout feature/BUG-4421 to switch to the fix branch. Then git pull to make sure you have the latest version of that branch. Then git log --oneline -3 to confirm the recent commits match what the developer described. Only then do you open the app and start testing.
Q2: In a GitHub PR diff, what do the red (−) and green (+) lines represent?
Red lines with a minus sign are lines that were removed from the file. Green lines with a plus sign are lines that were added. Unchanged lines are shown in grey for context. A block of red followed by green typically means the developer rewrote a section — read both to understand what changed and why.
Q3: A PR changes 4 files but none of them are test files. What does this suggest?
It could mean: the developer is relying on existing tests to cover the change (reasonable if the change is small and existing tests are thorough); or the developer did not write new tests (a risk worth flagging). Ask before testing: “Do the existing tests cover this change, or should new tests be added?” Also probe the changed areas more carefully yourself — you can’t rely on automated regression coverage if it hasn’t been updated.
9 ISTQB Mapping
CTFL v4.0 Section 2.1.4 — Testing in DevOps. The syllabus explicitly covers shift-left testing and the role of testers in CI/CD pipelines, which includes reviewing changes in version control before they merge.
Git is not a direct ISTQB exam topic, but version control literacy is an assumed baseline for any tester working in a modern NZ team. Expect questions about “shift-left” practices — this is the practical implementation of that concept.