5 Steps to Bug Regression: Day #4

This Step is where you use your data!

• You tested the fix in the right build
• You understood the fix and so were able to test accurately
• You tested until you were confident of the outcome
• Now – Comment!

Step #4:
Comment Thoroughly

If you comment in a way that gives the reader useful information, you have done your job as a professional and it is time well spent. If you comment like the average tester…well, let’s just hope you understand the difference by now.

Once you have assembled all of your data, you can Comment Thoroughly. This is very simple.

A Thorough Comment contains 3 statements:

1. What you did
2. What happened
3. What you are doing because of what just happened

Very simple…and yet.

Many testers don’t include enough information. Just like a developer that comments a bug they have resolved by writing (again, I quote): “fixed” – if you don’t include adequate information, you will cause confusion and more work for others.

Sadly enough, there are many testers in the workforce today who don’t understand why they should make this effort or what a Thorough Comment should look like.

To help you have a clear understanding of how to Comment Thoroughly, here are a few likely scenarios and the comment I would use:

Scenario #1:

• Bug with Reproducibility of Always
• I try 10 attempts at reproduction
• The bug does not occur

Scenario #2:

• Bug with Reproducibility of Intermittent (6 out of 10)
• I try 20 attempts at reproduction
• The bug does not occur

Scenario #3:

• Bug with Reproducibility of Intermittent (1 out of 25)
• I try 50 attempts at reproduction
• The bug does not occur

Scenario #4:

• Bug with any Reproducibility
• I try 3 attempts at reproduction
• On the 3rd attempt, the bug occurs

All that effort! See how easy that is?

Just state what you tested, what happened, and what action you took. That way, the next time anyone looks at that bug they will have an understanding of why it is in the state it is in. If you encounter a bug that has been closed, you can see what action was taken previously.

If you do anything to a bug, add information or change a field or change the assignment – whatever – you must Comment Thoroughly. When I encounter a bug that is Closed, but there is no comment as to why, I reactivate it. If a bug is Resolved, but there is no comment, I assign it to the person that resolved it and ask why.

There is no reason other than laziness to not Comment Thoroughly. Forgetting to or deciding not to thoroughly write what you did and what happened is strictly amateur hour. The QA field already has enough of that. Separate yourself from the crowd and do the job of a professional.

State your information with confidence and Comment it Thoroughly. It is a habit that will make your daily work easier and more organized and will show that you are an aware Quality Assurance Professional!