5 Most Common Bug Regression Mistakes:
Day #3

This cannot be stressed enough: Every single time you test a bug, change a Status, add information, Re-Assign, or modify a bug in any way you MUST add a comment to the bug. You must clearly state what you have done to the bug so that everyone will have the same understanding of the bug and what needs to happen to it next.

Mistake #3:
Not Commenting

Any changes made to a bug (especially changes to Status, Priority, etc.) will be mysteries or thought to be mistakes if the bug has no comment about who made the change, what the change was, the reason for the change, and the date of the change.

This applies to adding information as well. How else will someone know that the bug has more information now when they look at it than when they looked at it the last time if there is no comment telling them so?

To be fair, I should point out that some bugbases capture some or all of this information automatically. They will post automatically in a Comments or Bug History section who made a change and what change was made. In this way, there is some information visible to future readers of the bug. However, a bugbase cannot capture rationale.

Even automatic bugbase change tracking can’t reason WHY a change was made. So, even if your bugbase will automatically comment every time you change the Status of a bug, it is still up to you to provide a reason for the change. Go back and review 5 Steps to Bug Regression: Step #4: Commenting Thoroughly to get an idea of what to add.

I have worked on multiple projects where team members could not be bothered, or didn’t understand why, to add comments when they changed a bug. These project always become more maintenance-heavy (and thus more expensive) because of the effort wasted due to people who didn’t comment bugs appropriately – like making no comment at all.

As I am reviewing bugs daily, if I find one that has an action taken that isn’t commented, I immediately take corrective action. If the bug has no comment, it gets returned to its most recent previous state.

That is to say that if a bug has been closed, but there is no comment about who tested it, what version they tested, what happened, and what action they have taken, I Re-Activate the bug.

That’s right. Here is a bug and it’s Closed. But there is no reason given in the bug as to why it was changed from Resolved to Closed.

I must assume that someone made a mistake, because no one on my QA team would ever do such a thing (and just to be sure, I actually do ask if anyone did this – they have always truthfully assured me that QA had nothing whatsoever to do with an episode such as this).

So, here is a Closed bug. No stated reason for it to be closed, I Re-Activate it. And it might have been fixed.

It is less expensive and less risky to force a re-test of a bug the might be fixed than to ship an issue to the public and damage the company brand. Commenting is simple and takes little time - testing and retesting cost time and money.

Someone might have verified the fix. But since they couldn’t be bothered to share that information with anyone else, Re-Activate the bug and test it – or test it again as the case may be.

If a bug is going to be closed on my watch, I make sure that QA knows the bug is fixed.

Make everyone’s life (including your own) less complicated: Always Comment.