5 Most Common Bug Regression Mistakes:
Day #1

When executing Bug Regression, there are many hazards that a tester may encounter. I will explain each of these so that you will know them and be able to avoid all of them.

To set the stage for this part of our story, let us return to a point in the project just before QA begins performing Bug Regression. Let’s go back to a simpler time. Back to when a developer implements a fix.

The developer has looked at their list of bugs and has fixed each bug that has the designation of Priority 1. When they fix the bug, they should change its state to Resolved and assign it to QA…but in the real world, this doesn’t always happen.

Sometimes the developers are so caught up with so many bugs that they forget to Resolve and Assign one of their bugs, or they Assign it to QA without Resolving it. When this happens, it is up to QA to make sure that the appropriate steps are followed.

When it comes to Bug Regression, there are many places for many people to make a mistake. As an elite-level Software Quality Assurance Professional, it is your job to identify where the process is failing and to help the appropriate people correct the failings.

If you don’t, you won’t be able to do your job effectively. You will have to work around other’s mistakes and the integrity of your resulting data will be at risk.

So, when the time comes to perform Bug Regression, you must do your best to ensure that all the appropriate steps leading up to your work has been performed correctly. You should hold others accountable for their jobs just as you are accountable for yours. QA is a part of the Software Development Lifecycle, not separate from it, neither outside nor above it, but an integral part of it.

Here is a list of the most common errors made leading up to and during Bug Regression. Please do all you can to avoid or correct them and I assure you your daily work life will be much more pleasant.

5 Most Common Bug Regression Mistakes

1. QA Resolves A Bug
2. Non-QA Closes A Bug
3. Not Commenting
4. Commenting In The Wrong Place
5. Not Asking for Help

Mistake #1:
QA Resolves A Bug

Either a developer or producer should resolve a bug. They are the ones who know if a fix has been implemented, or a change made in documentation, or whether the current behavior is what they desire – they Resolve bugs! They are the parties accountable for changing the Status of a bug to a Resolved State.

QA DOES NOT RESOLVE BUGS! If you are testing and you notice that a bug is no longer occurring, great! Perform thorough testing to accurately validate that the bug no longer occurs and then make a comment in the bug.

Contact the person that the bug is assigned to and let them know what you have found – that the bug seems to be fixed. They can check their notes or the code and, if warranted, they can then Resolve the bug. Once Resolved, you are welcome to re-test the bug and then close it if it truly is fixed, but don’t assume that it is.

Have a developer check. Once they comment the bug and change its Status to Resolved, only then should you go forward.

Some think that it is a conflict of interest for QA to resolve bugs. Others believe that it removes the accountability from other parts of the project team if they are not the ones to resolve a bug. This is their responsibility, not the responsibility of QA.

Trust me; you will have plenty of other work to do. Let those who are accountable for resolving bugs do so, and concentrate on being accountable for you own job. Once you have mastered that, then we can investigate branching out.