5 Steps to Bug Regression: Day #1

After the bugs you have written are fixed, they get assigned back to you in a Resolved state and should be ready for testing. This is called “bug regression”. You are going to work through the fixes that the developers made to your bugs and see which ones were successful and which weren’t – “regressing a bug”.

This is where all of the hard work you have expended in testing, correct bug writing, and commenting all pay off. Because you did your work so cleanly, the developer had no problem understanding your bug. This allowed them to quickly deduce a fix for it and now they have implemented that fix. Your job now is to validate the success of that implementation.

Since you wrote the bug so clearly, you should have no problem following the Setup and Steps to Reproduce. By following the instructions that you wrote, it should be obvious very quickly if the fix was successful.

Undoubtedly, the Reproducibility you wrote is clear and accurate so you know how many attempts you must make to attempt to validate the bug, right? There is no question in your mind as to how many tries will get you the information you need, right?

Well, just to make sure that you finish the job in stellar fashion, let look at how to perform bug regression properly. You have tested, explained, and commented the bug and now it is time to wrap it all up and close the book on your bug.

In order to put your bug to rest, you need to follow the 5 Steps to Bug Regression.

5 Steps to Bug Regression

1. Know the Version
2. Understand the Fix
3. Validate Appropriately
4. Comment Thoroughly
5. Assign Accurately

Step #1:
Know the Version

In this first step of Bug Regression, it is your job to be sure you know which version of the product contains the fix. This is to say: you need to know which build to test in order to verify the fix. Then make sure you are using that correct version when you actually regress your bug.

There are two places in your bugbase where the version or build number that contains the fix may be listed. They are the Fixed In field and/or the Comment field.

The Fixed In field goes by several names; Fixed For, Fixed In, Resolved In, Version, etc. This field is used for stating which version contains the most current fix for a bug. It may show the version that the bug will be fixed in or that the bug is fixed in. This is because a fix may be planned for a version that has not been created yet.

The version or build that a bug is fixed in should also be available in the Comment field. This is where a clear statement should be made when a bug is fixed. It should read something like:“Fixed in version 1.0.a. Speaker volume is no longer affected when scroll button is selected.”

There you have a stated version for the fix and you have an explanation for the bug – perfect. If the Fixed In field matches the version stated in the Comments field, you’re in business!

Another place that the version in which the bug is fixed can be found is in the Release Notes. Release Notes are a document that is delivered with a build. Release Notes can contain several pieces of information useful for a tester:

• New features
• Changes to existing features
• Changes to documentation
• A list of bugs that were Deferred
• A list of bugs that have been fixed in the current version

That last bullet is what we are looking for here. A comprehensive set of Release Notes will clearly state for you which bugs were fixed in the version of the software that has been delivered to you for testing. With this list of fixed bugs in hand, you can begin regressing your fixed bugs.

This is the first Step in bug regression: Know the Version that a bug is fixed in.

The reason that I point out this, seemingly obvious, Step is that often the average tester overlooks this detail. When they do, they create confusion and show off that they aren’t paying attention to what they are doing.

Let me explain what happens:

• A bug is entered – Fine, everyone is happy
• Eventually a developer implements a fix for the bug – Good so far
• The developer changes the bug to a Resolved state then lists and/or comments the build in which the fix will appear. They assign the bug to QA for regression – but QA does not have this build yet
• The eager tester, seeing the bug Resolved and assigned to them (because it’s in their “My Bugs” bugbase query that they check daily), leaps into action without confirming which build the bug is fixed in – uh, oh…QA still does not have the build that contains the fix
• The tester regresses the bug in their current build and sees that the bug still occurs – because they are testing a build that does not have the fix
• The tester comments that the bug still occurs and assigns it back to the developer – even though the bug should not have been tested yet
• The developer is confused as to why their fix didn’t work

Because the tester regressed a bug on a build that did not have the fix, the following events have occurred:

• QA wasted time testing something they shouldn’t have
• The developer will have to figure out why the fix didn’t work – so they waste time attempting to determine whether their fix was correct although it may work just fine
• The project team will notice that QA tested for a fix that they did not have yet – this makes QA look like they are not paying attention, are wasting time, and are creating more work for the rest of the team.

This will only serve to lower the trust the rest of the team has in QA. This is preventable. Take the time to be sure you know which build a fix was implemented in before you begin testing it.

If you are not being provided with the information regarding which build a bug is fixed in, then you will not be able to test accurately. Request the information you need. This will pay off in the long run.

This may make the rest of the project team comment bugs more accurately and keep the bugbase up to date, but that is a good thing. They may not like that it seems like more work, but they will understand in the long run how this will help keep the project on track.

You can't make a program without broken egos.
~Internet Humor