Reviewing the Change Set Before You Start Testing

Learning Objectives

By the end of this lesson you will be able to:

Turn a build's change set into a prioritized test scope
Spot high-risk change patterns in a diff without reading code fluently
Ask a developer a sharper question because you looked at the diff first
Cite exact commits in a bug report

The Monday Problem

A build lands on your environment. The release note says: "Bug fixes and performance improvements."

You have four hours and two hundred candidate test cases. Guessing is the default, and guessing is why regressions ship.

Everything in this module has been building to the alternative. You already know how to list what changed and how to see it in detail. This lesson is the workflow that turns those two commands into a decision.

The Four-Step Review

Step 1: Get the range

Find the commit your last tested build came from and the commit for the new one. CI build pages, an About screen, or a version.txt in the deployment usually carry it.

git log --oneline 9c1e40a..4f2a1c9

The two-dot syntax means "commits after 9c1e40a, up to and including 4f2a1c9" — precisely the new work.

Step 2: Get the shape

git diff --stat 9c1e40a..4f2a1c9

 src/payments/currency.py        | 24 +++++++++++++-------
 src/payments/checkout.py        |  6 ++---
 config/test-env.yaml            |  2 +-
 docs/api/README.md              | 88 ++++++++++++++++++++++++++++++++
 4 files changed, 108 insertions(+), 12 deletions(-)

Before reading a single line of code you know: this build is about payments, it touched a config file, and 88 of the 108 added lines are documentation. Your test scope just collapsed from "the whole product" to "payments, plus whatever that config line does."

Step 3: Read the diffs that matter

git diff 9c1e40a..4f2a1c9 -- src/payments/currency.py config/test-env.yaml

Skip the docs. Read the code and config changes.

Step 4: Write the scope

Turn what you saw into a short, explicit list before you open a test case:

Currency conversion — rounding on 3-decimal currencies (currency.py changed the rounding call)
Checkout totals — regression, since checkout.py calls into currency.py
Slow-environment behaviour — DB timeout dropped 30s → 5s
Skip: documentation-only changes

That list is defensible. When someone asks why you didn't test the login flow, the answer is "nothing in this build touched it", not "I ran out of time".

The same build, described by two sources:

  WHAT THE RELEASE NOTE SAYS      WHAT THE REPOSITORY SAYS
  ──────────────────────────      ─────────────────────────────────────────
                                  src/payments/currency.py   +24  rounding
   "Bug fixes and                 src/payments/checkout.py    +6  calls it
    performance improvements"     config/test-env.yaml        +2  30s → 5s
                                  docs/api/README.md         +88  docs only

  Test scope:                     Test scope:
    the whole product,              1. currency rounding, 3-decimal cases
    or whatever you can             2. checkout totals (regression)
    finish before 6pm.              3. slow-environment behaviour
                                    skip: documentation-only change

Both describe the same four hours of work. Only one of them can be defended in a meeting.

Reading Diffs Without Reading Code

You do not need to be a developer to get value here. These patterns are visible to anyone.

Numbers and limits changed. timeout: 30 → 5, max_retries: 3 → 1, LIMIT 100 → LIMIT 1000. Boundary changes are the highest-yield thing a tester can find in a diff, and they're the most likely to go unmentioned in a release note.

Conditions flipped. A > that became >=, an and that became or, a ! that appeared or vanished. Off-by-one and inverted-logic bugs live here.

A deleted check. Removed lines (-) that contained words like validate, check, if, assert, or required mean a rule that used to be enforced may not be anymore. Test what that rule was protecting.

Config and environment files. Connection strings, feature flags, timeouts, credentials paths. These change behaviour dramatically with tiny diffs, and they're frequently the actual cause of "it works on my machine".

A very large diff in one file. A rewrite, not a fix. Treat the whole area as new, not as a regression check.

Files nobody mentioned. If the ticket said "fix the tooltip" and the diff touches the session handler, that's a question worth asking before you test, not after.

Two Things This Doesn't Replace

Exploratory testing. The diff shows what was touched. Bugs frequently appear in code that wasn't touched but depended on code that was. Use the diff to aim, then look wider.

Talking to people. A five-minute conversation with the developer, armed with what you saw in the diff, is worth an hour of guessing. "I see the rounding call changed in currency.py — which currencies does that affect?" gets a real answer. "What did you change?" gets a shrug.

Citing Commits in Bug Reports

Once you're reading history routinely, your bug reports get sharper:

Reproduced on: commit 4f2a1c9 (staging, deployed 2026-08-17 09:50) Last known good: commit 9c1e40a Suspected change: src/payments/currency.py, rounding call at line 88 changed in 4f2a1c9

That report is nearly a diagnosis. It also removes the entire "which build were you on?" round trip that eats a day of most bug lifecycles.

Pro Tip: Save your scope list in the ticket or your test notes. When the same area breaks two sprints later, that note is the fastest existing record of what was already covered and what wasn't.

Key Takeaways

git log --oneline A..B lists exactly the commits between the build you tested and the one you're testing
git diff --stat A..B gives a change map that turns "the whole product" into a focused scope
Changed numbers, flipped conditions, and deleted checks are high-risk patterns visible without coding skill
Config and environment changes are small diffs with outsized behavioural impact — never skip them
Diff-based scoping aims your testing; it does not replace exploratory testing or a conversation with the developer