Do you use bug templates? You should. Unfortunately, good bug reports require lots of overhead. It’s not enough to just enter your perfected repro steps. You have to enter a severity, priority, area, version tested, assign it to someone, etc. Because these tedious fields are often entered with the same values, you can make logging bugs a quicker and more pleasant experience by starting with a template that already has your typical entries. How? This, of course, depends on your bug tracking system. Lately, I’ve been using Microsoft VSTS or Mercury Quality Center (TestDirector).

If you use VSTS, download the TFS Work Item Templates Power Tools release. I used it to create various templates for the common chunks of bug entries I submit. All my templates also add starter text in the description field like “Repro Steps:” which is the heading above the repro steps.

I hate when stuff works.

I think testing is at its most boring when stuff works. Yesterday my day was spent verifying one feature. It took me the entire day to set up and execute eight “happy” tests. The “happy” tests were all positive paths I needed to verify. All eight tests passed and I have to admit, I’m disappointed. If I don’t have a chunk of bugs logged at the end of a session I typically feel like I’ve accomplished nothing. And I figure the rest of the team must agree. Can anyone relate?

But this is silly because our purpose as testers is not to log as many bugs as we can. That would be too easy. We’re also supposed to determine what does work. The trouble is, it’s just not as fun. So how can we feel some sense of reward or accomplishment by verifying features that work?

Here are a few ideas…

1.) For starters your passed tests should be logged somewhere. In my case, they’re in the Test Lab module in Test Director (both automated and manual tests). If you use James Bach’s Session Based Test Management process, you have completed session sheets or charters stored in a directory. Seeing little green “PASS” indicators next to my eight tests helps me feel a little pleasure and reflects my work to some extent.

2.) Another thing I tried was to verbally tell my devs said feature worked well. Certainly they appreciated the complement and I felt as if they would appreciate my efforts.

3.) Perhaps I should have mixed up my session with “unhappy” tests. Obviously, said feature includes bugs. Maybe it’s worth keeping my enthusiasm high by allowing myself to sneak some nasty tests in with the friendly ones.

4. ) Or perhaps this is just a reality of software testing we need to accept. Testers only appear valuable when they uncover problems.

I would love to hear anyone else’s ideas on how to feel valuable during the dry spells, where your bug discovery is low or absent.

I love reading software tester blogs but sometimes I can't relate. Many of the topics are too academic to have any practical value for my daily testing struggles. Test blogs and forums often discuss test approaches (e.g., manual vs. automated, scripted vs. exploratory). These are interesting topics but many are outside my scope of control. I can influence my managers to some extent, but I also have to operate within the processes and tools they dictate.

I work for a QA group in a large company that is very metric hungry when it comes to testing. Most of my managers love manual detailed test cases, requirements coverage, and other practices that create administrative work for us testers, thereby reducing our available time for actual testing. In practice, I think most of my peers test the way I do, attacking a feature with an exploratory type approach, then updating execution results of a handful of test cases that give a vague and superficial representation of what was tested.

Recently, some of my managers have also decided we should attempt to automate most of our tests, which from their perspective, seems realistic and should free up our time because we can just fire off automated tests instead of wasting time with manual execution. One manager tells of how in the good old days when he was a tester, he would launch his automation suite and take the rest of the day off. This romanticized version of test automation is far from anything I can fathom...and I think he may be exaggerating.

So I'm left in the awkward position of trying to be a valuable tester from my manager's perspective but also from the perspective of the software team I support. My daily struggles are typically not very romantic and my ideas are not groundbreaking. However, I do feel myself improving with each question I answer. And I don't think I'm the only tester to waste energy on questions like these...

• Did someone log this already?
• How much more time should I spend investigating this bug?
• Should I reopen the bug or log a new one?
• Is it a bug?
• Should I be embarrassed using a stop watch to performance test the Login screen?
• Was that test worth automating?
• Is it ready to test?
• Should I log it without repro tests?
• Am I bored?
• Am I valuable?
• Did I test this already?
• Is my goal to find as many bugs as possible?
• Who do I really serve?
• Do my bugs suck?
• Is my job lame?
• Can I log a bug because I hate the way the UI looks?
• Am I irritated with my AUT?
• When is my job done?
• Did my devs smoke crack while they wrote this?
• Does anyone really get performance testing?
• Does my pride hurt when my bugs get rejected?
• What the hell is this feature supposed to do?
• Should I be spending time logging bugs on the hourglass pointers that don't trigger?
• Do I posses any special abilities or am I just an A-hole with the patience to submit another fake order for the 300th time?
  

Hopefully this blog will find its niche discussing the unromantic software test struggles of the hands-on tester. I'm not a manager. I'm not a consultant. I was never a professional developer. I'm not cool enough to have a beard with braids in it. I haven't written any testing books. And I haven't spoken on testing in front of a large audience. However, I have been practicing the art of testing software for the last seven years and I've experienced many practices that do and do not appear to work. I plan to share those here and I hope you will show me where I am wrong, offer your own solutions, or give me a pat on the back. See you soon.