Learning Objectives
By the end of this lesson, you'll be able to:
- 🎯 Define re-testing and explain when it happens
- 📋 Use the original bug report as a re-test script
- 🔄 Understand the full bug lifecycle from "Fixed" to "Closed" or "Reopened"
- ✅ Know what to write when you reopen a bug
The Big Idea
A developer says a bug is fixed. You say: prove it.
Not rudely. But professionally, you go back to the original bug report, follow the exact steps that produced the bug, and check whether those steps still produce the problem.
This is re-testing — the simplest, most fundamental QA activity there is.
And yet it's often done wrong. People skip steps, test different scenarios than the original, or forget to document their results. This lesson fixes that.
What Is Re-testing?
Re-testing is the process of executing the exact reproduction steps from a previously failed bug report to verify that the fix works.
Three key words:
- Exact — same steps, same data, same environment (as much as possible)
- Previously failed — you're testing a known bug, not exploring new functionality
- Verify — your goal is to confirm the fix, not to find new bugs
Re-testing is not exploratory. It's not regression. It's not sanity testing (though sanity testing uses a similar approach). It's the most targeted test in your toolkit: one bug, one set of steps, one verdict.
The Re-test Workflow
Step 1: Find the original bug report
The bug report is your script. It tells you:
- What environment it occurred in
- What steps to follow
- What the expected behavior should be
- What the broken behavior was
Step 2: Set up the same environment
Match the original environment as closely as possible:
- Same browser/OS if mentioned
- Same test account or data
- Same application state (logged in, specific page, etc.)
Step 3: Execute the steps exactly
Follow the reproduction steps from the bug report. Don't skip steps. Don't substitute equivalent actions. Execute precisely.
Step 4: Compare actual vs. expected
- If the expected result now happens → ✅ fix confirmed
- If the bug still occurs → ❌ fix didn't work
Step 5: Document and act
If fixed:
- Add a comment: "Re-tested on [date] in [environment]. Bug no longer reproducible. Closing."
- Change status to Closed (or Verified, depending on your workflow)
If not fixed:
- Add a comment: "Re-tested on [date] in [environment]. Bug still reproducible. Steps below: [paste steps + actual result]. Reopening."
- Change status back to Open (or Reopened)
- Notify the developer
The Bug Lifecycle
New → In Progress (dev) → Fixed (dev) → Re-test (QA) → Closed ✅
└→ Reopened → In Progress → ...
When a developer marks a bug as Fixed, it enters a Re-test state — which is your cue. You own this state. You decide the outcome.
Important: "Fixed" means the developer believes it's fixed. "Closed" means QA has verified it's fixed. These are different things. Never let bugs skip from Fixed to Closed without a human QA re-test.
Real-World Example
Bug #412: "Clicking 'Delete Account' shows a confirmation dialog, but clicking 'Confirm' does nothing — the account is not deleted."
Steps to reproduce:
- Log in as user
- Go to Settings → Account
- Click "Delete Account"
- Click "Confirm" in the dialog
Expected: Account is deleted, user is logged out Actual: Nothing happens, dialog closes, user remains logged in
Your re-test:
- Log in as user (fresh test account)
- Go to Settings → Account
- Click "Delete Account"
- Click "Confirm"
- Result: User is logged out, account page returns 404 ✅
Comment: "Re-tested 2026-05-16 on Chrome 125 / macOS. Account deletion now works correctly. Closing."
Pro Tips
💡 Always re-test in the same environment as the original report. A fix that works in Chrome might still fail in Firefox. Match the environment, then optionally test in others.
💡 Use a fresh test account when the bug involves user data. Reusing a dirty account can produce false positives (the data was already changed) or false negatives (the fix applied to old data).
💡 One re-test can reveal a regression. If you fixed the delete flow but now the confirmation dialog doesn't open at all, you've found a regression. Log it as a new bug, but still close the original one if the original issue is resolved.
Summary
- 🔁 Re-testing = following exact original reproduction steps to confirm a fix
- 📋 Your script is the original bug report — follow it precisely
- ✅ Confirmed → update status to Closed with a comment
- ❌ Still broken → reopen with steps + actual result as evidence
- 🚫 "Fixed" ≠ "Closed" — QA re-test is the required step between them
Up next: Lesson 2.2 — Regression Testing: because sometimes fixing one bug quietly breaks another. 🦋