Verifying fixed bugs logged by you is easy. You’re a tester. You logged a proper bug, with repro steps, expected results, and actual results. You remember the issue.

But what about those bugs logged by non-testers that you never even had a chance to experience? You certainly need to verify their fix. However, how can you be sure you understand the bug?

Here is what I try to do.

First, I track down to person who logged the bug. I ask them how it was discovered. Knowing this info will solidify the repro steps (if there were any).

Second, I experience the bug in its unfixed build. This sometimes means preventing the fix from being released to the environment I need to verify it on (so I have time to repro it). If I experience the problem I am usually confident I can verify its fix.

Third, I determine what was done to fix the bug? I can usually identify the dev from the bug history. Even if the bug has the dev comments about its fix, devs are always thrilled to discuss it at length.

Finally, while talking to the dev, I squeeze in the important question, “What related functionality is at risk of breaking?.” The answer to this question helps narrow down my regression test goal to something realistic.

Am I missing anything?

2 comments:

  1. crayons are for coloring said...

    Yes you forgot the most important last step:

    Hug the developer that fixed the bug. Here's some motivation for testers to hug developers: http://blip.tv/file/1061088

    P.S. - If you come to my cube and try to hug me -- I will punch you in the face. Hard.

  2. Eric Jacobson said...

    Crayons Guy,

    That video is hilarious! Despite the fact that it has absolutely nothing to do with my post.

    I'm coming over there to hug you right now. I have glasses so you can't punch me.



Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.