Testing practice: For Reproduce the old failure first, define a reproducible starting state, perform one controlled change at a time and record the result. Good testing evidence helps another person repeat the same path without guessing what happened.
Evidence quality: A useful report separates observation from theory. Record version, device context, steps, expected result and actual result while removing passwords, authentication codes and unrelated personal information from evidence.
Reproduce the old failure first
Use the original steps on the old or known-failing build when possible.
This confirms that the test actually targets the reported bug.
Run the same steps on the fixed build
Keep the device and starting state as similar as practical.
A pass should match the expected result without hidden workaround.
Test adjacent paths
A change to login, camera, navigation or validation can affect nearby screens.
Identify the components touched by the fix and test related workflows.
Test negative cases
A fix can accidentally allow invalid input or bypass an error check.
Repeat the boundaries that the feature is supposed to reject.
Record the tested build
Regression results are meaningful only when linked to the version containing the fix.
Keep the build number in the closure evidence.
Common mistakes to avoid
- Testing a different path from the original bug.
- Checking only the happy path.
- Forgetting the fixed build number.
Practical checklist
- Repeat original steps.
- Use the fixed build.
- Test adjacent flows.
- Test negative cases.
- Record closure evidence.
Frequently asked questions
Why test nearby features?
Shared code or UI changes can introduce side effects.
Should the original reporter retest?
It can help, but any tester with the same reproducible conditions can verify the fix.
What closes a bug?
A verified expected result on the intended fixed build, with appropriate regression coverage.