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.
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.
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.