5 Steps to Bug Regression: Day #2

Once you know which build contains the fix and you have that build to test on, you can move on to the next step: Understand the Fix. This means that you must have a clear knowledge of the fix that was implemented. You don’t need to know what each line of code does, but you must know what the expected behavior is now that the fix has been made.

Step #2:
Understand the Fix

Sometimes this is as simple as: “The help menu should open” – OR – “Program will close but the computer will not crash.” If this is the case, it probably synchs up well with the Expected Result you stated originally.

When this happens, it will be easy and straightforward for you to test the bug to verify whether the fix worked or not. For many bugs, this situation is very clear and you will understand the fix without any further input.

If, however, the developer has not stated the fix clearly or has not stated the fix at all, you better go get some clarification. If the developer’s comment is (and I quote): “fixed” then you need to go see your developer about expanding their vocabulary.

As much as it is your job to write up a bug in such a way that anyone can understand it, it is up to the developer to explain what they fixed. If they don’t, you have no way of accurately testing it. They will need to be able to explain to you what was fixed if it is not readily obvious in the bug.

So, if the developer that Resolved the bug has not been explicit enough regarding their fix, what should you do? Fortunately, we cover this in detail in our 10 Skills of Elite Testers course: Be nice and go ask. That’s all. Know what you need to ask them and do so politely.

Most developers are very happy to discuss the wonders of their code. All you want is for them to explain what the fix was so that you can test it. They should be happy to detail their fix for you. If you ask nicely, they will welcome your questions in the future.

Once they have explained the fix, get them to tell you what else their fix may have affected. Did their fix put any other functionality at risk, in their opinion? They are most often very forthcoming about whether they think it did or not. So listen to what they have to say so that you can target your testing most effectively.

Once they have given you all the information you need, say thank you and go test. And then remember that they gave you their educated opinion, and as nice as they are, you can’t trust that they are right 100% of the time about the functionality their fixes affect.

If they never made a mistake and were always 100% right, you wouldn’t have a job testing. So use the information they have given you to accurately regress the bug. Then take the information they gave you about potentially affected functionality and check that too. This is the thorough way to regress all bugs.