Building a Regression Timeline from History

Learning Objectives

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

• Turn a vague regression report into a bounded time window
• Assemble the commands from this module into one repeatable routine
• Write a bug report that names the breaking commit
• Recognise when to escalate to git bisect

Why a Timeline

"It used to work" is the least actionable sentence in testing. A timeline converts it into something a developer can act on immediately:

Worked at v2.4.0 (11 July). Broken at v2.5.0 (25 July). The only change to LoginView.js in between is 8f3c2a1 (Marta, 14 July), which renamed the button ID.

That is no longer a report — it is a diagnosis. The whole of this lesson is the routine that produces it.

Step 1: Bound the Window

Get a known-good point and a known-bad point. Anything works: release tags, dated builds, or just "it passed in Monday's nightly run".

git tag --sort=-creatordate | head -5

v2.5.0
v2.4.2
v2.4.1
v2.4.0

Then verify each end rather than assuming:

git switch --detach v2.4.0
npm test -- tests/auth              # passes → good
git switch --detach v2.5.0
npm test -- tests/auth              # fails  → bad

Two minutes here saves an hour of searching in the wrong window. Return to your branch afterwards with git switch -.

Step 2: List What Changed

git log --oneline v2.4.0..v2.5.0

Everything in the window. Often too much to read, so narrow to what the failing test touches:

git log --oneline v2.4.0..v2.5.0 -- src/views/ tests/auth/

And see the shape of it:

git diff --stat v2.4.0..v2.5.0 -- src/views/

 src/views/LoginView.js    | 12 ++++++------
 src/views/SignupView.js   |  3 ++-
 2 files changed, 9 insertions(+), 6 deletions(-)

Twelve changed lines in the file your test exercises. That is a very short list of suspects.

Step 3: Find the Specific Change

Now the tools from the rest of the module.

If the failing element still exists in the code:

git blame -w -L 38,45 src/views/LoginView.js

If it has disappeared:

git log -S "login-btn" --oneline v2.4.0..v2.5.0

If it changed value rather than appearing or disappearing:

git log -G "login-btn" --oneline v2.4.0..v2.5.0 -p

Any of the three lands you on a commit ID.

Step 4: Read the Commit

git show 8f3c2a1

Read the whole thing, not just the line you were looking for. Three questions to answer:

1. Was the change deliberate? The message usually says. A ticket reference in it is worth following.
2. What else did it change? Often the real story. A rename that also touched three other files means three other tests may be affected.
3. Is it live?

git branch --contains 8f3c2a1
git tag --contains 8f3c2a1

Whether the change is in production, in a release candidate, or still only on a branch changes the priority of your report entirely.

Step 5: Write It Up

Everything above fits into a report a developer can act on without asking a single follow-up question:

Login smoke suite fails at auth/login.spec.js:24 — selector #login-btn not found

Working: v2.4.0 (11 July) — full suite green. Broken: v2.5.0 (25 July) — 4 of 11 auth tests fail.

Cause: commit 8f3c2a1 (Marta Kovalenko, 14 July) — "Rename login button ID for the new auth flow (PAY-4102)" — changed LOGIN_BUTTON_ID from login-btn to login-btn-v2 in src/views/LoginView.js:41.

Scope: git branch --contains 8f3c2a1 shows it is on main and in v2.5.0, so it is in production.

Question for the team: is login-btn retired for good? If so this is a test-maintenance task and I will update the auth suite. If the old ID was meant to stay for backward compatibility, this is a product defect.

Note what the last paragraph does. It states what you know, asks the one thing you cannot determine yourself, and offers to do the work if the answer is the simple one.

When to Reach for git bisect

Sometimes there is no string to search for. The tests are flaky at v2.5.0 and fine at v2.4.0, the window holds 200 commits, and nothing in the diff looks obviously related.

git bisect start
git bisect bad v2.5.0
git bisect good v2.4.0
# Git checks out a commit in the middle; run your test, then:
git bisect good      # or: git bisect bad
# repeat until Git names the culprit
git bisect reset     # always, to return to your branch

Binary search: 200 commits takes about eight steps. And if your test is scriptable, Git will do the whole thing for you:

git bisect run npm test -- tests/auth

Bisect is beyond this course's scope, but it is the natural next tool and it is worth knowing the name when the pickaxe runs out of road.

Pro Tip: Do this investigation before filing, not after someone asks. Five extra minutes at report time routinely converts a two-day round trip into a same-day fix — and it is the clearest way for a tester to demonstrate what they add beyond finding the failure.

Key Takeaways

• Bound the regression between a verified good point and a verified bad point
• git log --oneline good..bad -- <paths> narrows the suspects to a readable list
• Use blame for lines that still exist, -S for ones that vanished, -G for changed values
• git show on the culprit answers whether it was deliberate and what else it touched
• git branch --contains / git tag --contains establish whether the change is live
• Name the commit in the report, and state clearly the one question only the team can answer
• When nothing in the diff looks related, git bisect finds the commit in logarithmic time