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?

While cleaning my desk, I discovered a brand new promotional Mercury cap. Since I’m not a big fan of Mercury (e.g., TestDirector, QuickTestPro), I decided to award the cap to the tester on my team who could log the most bugs in a given week.

Life would be so much easier if our main goal were simply to log as many bugs as possible. Most of you will agree with me, that given enough time, you can find bugs in any piece of software thrown at you. Sure, they may be stupid bugs that nobody cares about, but you’ll find them.

Let’s face it. Testers don’t have very concrete goals. “Ensure the quality of the software”. Sometimes it’s fun to get a little competitive with each other and just focus on primitive stuff, like flooding your devs with bugs!

I think they should.

The less selfish you are about your bug list, the more bugs you’ll get logged, and the more info you’ll have about the state of the AUT. In my team, the devs, and the business people who write the requirements, all log bugs. This is an Agile team so we have the luxury of continuous business testing.

How are their bug reports? Terrible. The dev’s bug reports are usually too low level for me to understand. The business people’s bug reports usually lack repro steps, include multiple problems, and rarely describe what they expected. That being said, I wouldn’t trade them for anything.

As poorly as said bug reports may be written, they are tremendously valuable to me. Although a brief face-to-face is sometimes necessary to decipher the bug description, some of these bugs identify serious problems I have missed. Others give me ideas for tests (from a dev perspective or a business perspective). And it’s more convenient to retrieve these from the Bug list rather than rooting through email. Finally, I think most team members enjoy the ability to log bugs and even consider it a privilege.

I have some non-testers on my team who have logged more bugs than some of the testers on my team. Scary, huh? The point is, if a non-tester wants to log bugs, don’t feel threatened by it. Embrace it!

I’ll talk more specifically about how I handle bugs written by non-testers in a future post.