Git & GitHub for Testers — Junior Learning

1 The Hook — Why This Matters

A developer merges a feature to the main branch. By the time the QA team gets to it, the code is already in production staging. The feature breaks, but now it is tangled with five other changes in the same merge. The QA team spends two days trying to isolate which developer caused the issue. The meeting could have been 30 minutes if one tester had checked out the feature branch, tested it in isolation, and caught the bug before the merge.

In modern software teams, testers do not wait for complete builds. You learn Git. You check out branches. You read pull requests. You test features locally in 15 minutes instead of waiting two weeks for a staging deployment. The testers who understand version control ship features faster, catch bugs earlier, and become indispensable to their teams.

2 The Rule — The One-Sentence Version

Every pull request is a testing opportunity: read the diff, understand what changed, check out the branch, test it locally, and report findings before the merge.

Git is not just for developers. Version control is how your team communicates what is changing, when, and why. You need to read that conversation to test effectively.

3 The Analogy — Think Of It Like...

Analogy

A building renovation with blueprints.

Version control is the blueprint archive. A developer proposes a change: "I am rewiring the kitchen and updating the electrical panel." The pull request is the proposed blueprint. Your job as a tester is not to wait for the completed renovation; it is to review the blueprint before the work starts, understand what is changing, spot risks ("You moved the outlet too close to the sink?"), and then watch the work happen locally in your test kitchen. If you only inspect the whole building after all renovations are done and everything is merged, you have missed the window to catch issues early.

4 Watch Me Do It — Step by Step

Here is the complete workflow for testing a feature from pull request to merge. The scenario: a developer named Sam has created a pull request called "Add password reset flow" and assigned it for testing.

Read the pull request on GitHub Open the PR. Read the description: what is Sam trying to do? Look at the "Files changed" tab. This shows every file Sam modified. You can see the exact lines of code that changed, highlighted in red (removed) and green (added). Read the diff to understand scope and risk.
Understand what files were modified If only JavaScript changed, backend integration is unlikely. If the database schema changed, you need to test data migration. If the UI and API both changed, test both layers. The diff reveals the testing scope.
Check out the feature branch locally Copy the branch name from GitHub. Run git checkout feature/password-reset. Your local code now mirrors Sam's feature branch exactly. You have the same version developers are testing.
Start the application locally Run npm start or docker-compose up or your project's startup command. The feature is now live in your local environment, not deployed anywhere, so you can break it freely.
Test the feature according to the description Follow the user story in the PR description. Test the happy path, edge cases, and error handling. Take notes of anything that breaks. This is your chance to test before the entire team depends on it.
Check the commit history for context Run git log --oneline to see the commits in this branch. Each commit message explains why a change was made. Understanding the reasoning helps you write better test cases.
If you find a bug, create an issue Post a comment on the PR with steps to reproduce, screenshots, and expected vs actual results. Link it to the diff line that caused it. The developer can fix it immediately, and you can re-test in 5 minutes instead of waiting for the next staging build.
Switch back to main after testing Run git checkout main and git pull to sync back to the latest production code. You are now ready to test the next pull request.

Git commands for testers (cheat sheet)

Command	What it does	When to use it
`git clone <url>`	Copy the entire repository to your computer	First time downloading the project
`git status`	Show which branch you are on and if you have uncommitted changes	Before testing, to confirm you are on the right branch
`git branch`	List all local branches; mark the current one with *	To see which branches you have downloaded
`git checkout <branch>`	Switch to a different branch (pull requests, feature branches, etc.)	When testing a new feature PR
`git pull`	Download and merge the latest changes from the server	After switching branches, to get the latest code
`git log --oneline`	Show recent commits with their messages	To understand what changed and why
`git diff <file>`	Show what changed in a specific file locally	Comparing your changes to the version on the server

Real Workflow Example: Testing a Login Improvement

A developer, Alex, opened a pull request called "Improve login error messages." Here is what you do:

$ git status
On branch main, up to date

$ git checkout feature/improve-login-errors
Switched to branch 'feature/improve-login-errors'

$ git log --oneline
a7f2e1c Add error message i18n
b3d9c4e Improve login validation feedback
c2e8b9d Update tests for new error messages

$ git diff HEAD~3..HEAD -- src/pages/Login.js
(shows the 3 commits of changes to the Login page)

$ npm start
(your app starts with the new feature)
          

Now you open the app and test: Try invalid email format (old message said "Invalid"), now it says "Please enter a valid email address (user@example.com)." Much clearer. Try wrong password (old message said "Failed"), now it says "Email or password incorrect." No user enumeration. Try too many failed attempts: the UI now says "Account locked for 15 minutes. Check your email for a reset link." This is helpful context. You test the reset link, verify it works, and post a comment on the PR: "Tested on branch feature/improve-login-errors. Happy path works. Error messages are clear. Tested on Chrome, Firefox, Safari. Ready to merge." The PR merges. The whole team now benefits.

Pro tip: Always test the actual PR branch, never just the main branch. Main will have the code after it merges, but until then, you need to verify the branch works. Testing main after the merge is too late; the bug is already live.

5 When to Use It / When NOT to Use It

✅ Test a feature branch when...

A pull request is open and assigned for testing
You want to catch bugs before they merge to main
The change is complex and needs careful exploration
A developer asks "Can you test this locally?"
You are doing pre-merge smoke testing

❌ You don't need to if...

The change is purely cosmetic (color, font size)
The PR is documentation-only
You don't have a local development environment set up
The feature is already deployed and live
The change is behind a feature flag and not active yet

Before you test a PR branch, ask:

Is there a PR description explaining what changed and why?
Can you read the diff to understand the scope?
Do you have a local environment where you can run the code?
Do you know the acceptance criteria from the user story?

6 Common Mistakes — Don't Do This

🚫 Testing the wrong branch

I used to think: If the code works on main, the feature is fine.
Actually: The feature branch is what you test. Testing main after the merge is too late; you have already missed the window to give feedback. The developer has moved on to the next feature. Always test the feature branch before the merge. That is when your feedback is most valuable.

🚫 Ignoring the pull request description

I used to think: I will just test whatever I see.
Actually: The PR description is your acceptance criteria. It tells you exactly what the developer intended to do. If the description says "Add password reset via email," your tests must verify the email is sent, the link works, and you can reset the password. If you skip this, you might test the wrong things and miss the actual feature.

🚫 Forgetting to check the diff

I used to think: Testing is just clicking around the app.
Actually: Reading the diff is testing. If the diff shows the developer added a new database column, you know to test that column immediately. If the diff shows they removed a validation rule, that is a risk area. The diff is a map to high-risk areas; read it first.

When branch testing fails

You switch to the wrong branch. You thought you were testing feature/login-redesign, but you are still on main. You test, everything works, you say "Ready to merge!" but you were testing the old code. Always run git status and git log --oneline to confirm you are on the right branch before testing. It also fails when you test only the UI path and ignore the API. The UI might accept the feature, but the backend might reject it. Use browser DevTools or Postman to test the API layer too.

7 Now You Try — Reading a Real Diff

🎯 Interactive Exercise

Scenario: You receive a pull request called "Add two-factor authentication (2FA)." The PR description says: "Users can enable 2FA via SMS. When logging in, if 2FA is enabled, they are prompted for an OTP code."

The diff shows changes to:

src/pages/Login.js (adds OTP prompt after password)
src/pages/Settings.js (adds "Enable 2FA" button)
src/services/auth.js (adds verify_otp() function)
database/migrations/2024_add_2fa_columns.sql (adds mfa_enabled and phone_number columns)

Your task: List at least four test cases you would run immediately based on reading the diff. Do not execute them; just write them down based on what you learned from the changes.

Four critical test cases based on the diff:

Settings page 2FA toggle. Navigate to Settings. Enable 2FA. Verify the "Enable 2FA" button becomes "Disable 2FA." Verify you are prompted for a phone number and it is validated (NZ format). Verify a confirmation SMS is sent.
Login flow with 2FA enabled. Enable 2FA in Settings. Log out. Log back in with the correct password. Verify you are prompted for an OTP code instead of being logged in immediately. Verify the prompt says "Enter the code sent to your phone."
OTP validation. During login with 2FA, enter an invalid OTP (wrong code, expired code, reused code). Verify each is rejected with a clear error. Enter the correct OTP and verify login succeeds.
Database schema. Check that the mfa_enabled and phone_number columns were created correctly. Verify a user with mfa_enabled=true is prompted for OTP, and a user with mfa_enabled=false is not.

Tip: The diff revealed four areas to test: new UI button, login flow change, API function, and database schema. You did not need to run the code; the diff told you what to test. This is the power of reading the diff first.

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you are ready to practice.

Q1. What does git checkout <branch-name> do?

It switches your local code to match that branch. If you run git checkout feature/login-redesign, your entire codebase is now the feature branch version. All files, all code, all history match that branch. You can run the app and test that exact feature without affecting main. This is how you test pull requests before they merge.

Q2. Why is reading the diff important before testing?

The diff shows exactly what changed: which files, which lines, additions and deletions. It reveals the scope of testing. If the diff shows only UI changes, you know the backend is untouched. If it shows database migrations, you know to test data integrity. If it shows a security fix, you know to test that vulnerability. Reading the diff takes 2 minutes and saves you hours of aimless testing.

Q3. What command confirms you are on the correct branch before testing?

git status tells you the current branch and whether you have uncommitted changes. git log --oneline -5 shows the last 5 commits, letting you confirm you are looking at the right feature. Always run both before testing to avoid the "I thought I was testing feature X, but I was on main" mistake.

9 Interview Prep — Know These Cold

These are questions Kiwi employers ask junior testers about Git and version control. Have an answer ready.

Q1. How do you test a feature that is in a pull request?

I read the PR description to understand what was built. I read the diff to see which files changed and what the risk areas are. I check out the feature branch locally with git checkout. I start the application and test the feature against the acceptance criteria. If I find a bug, I comment on the PR with reproduction steps so the developer can fix it before the merge.

Q2. What is a branch and why do developers use them?

A branch is an isolated copy of the code. Developers create a branch to work on a feature without affecting the main code. Multiple developers can work on different branches in parallel. When the feature is done and tested, the branch is merged back to main. As a tester, branches let you test features in isolation before they go to production.

Q3. What is the difference between main and a feature branch?

Main is the production version of the code. It is stable and has been tested. A feature branch is a developer's work-in-progress. It has new code that has not been tested or merged yet. Your job is to test the feature branch and report bugs so it can be fixed before merging to main.

Q4. Why is testing before the merge better than testing after?

If you test before the merge and find a bug, the developer can fix it immediately while the context is fresh. If you test after the merge, the code is already live in staging or production, and now it is tangled with other changes. Reverting is painful. Plus, the developer has moved on to the next feature. Testing before the merge is faster and less disruptive.

10 Next Step

You now know how to navigate version control, understand pull requests, and test features locally. The next skill is debugging: when something breaks, how do you find the root cause?

All junior learning Practice: PR Review → Next: Logs & Stack Traces →