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.
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
Of course there's always more, right? You could perf/load test them. You could inject some sad path logic into the tests -- doing things out of sequence; high order characters; cutting power in the middle of a process to see how the system recovers; etc.
But I agree, and it's another reason metrics can be really important. With that data over time and across the app, we can see what areas of the software have the most (or least) bugs and then we can concentrate on those areas with the most trouble -- and we'll have actual data (not just anecdotal "I *think* this area is buggy) to guide and support our decisions.
"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."
I don't ever get any accolades from you -- not that I go around everyday wishing for affirmation from you to compliment my mad coding skillz.
Also, I don't quite understand the logic as to why you're unhappy when stuff works. Wouldn't that add consoliation that the developer tried testing it before throwing the latest bits over the wall to you guys? Should I be writing more buggy code to make you "happy"? (As if I'm not already writing buggy code...)
It seems you guys mainly do black box testing. Another thing you could probably do if you really want to find a bug so that you feel more "valuable" is if you're bored you could try and read the code you're testing to see if you can spot a logic flaw. Sometimes reading through the code or at least glancing through it you can pick up some things that you wouldn't have thought to test otherwise. Although I do admit that reading through developer code can be difficult and not for the feint of heart. I have trouble reading other people's spaghetti code at times also.
Pros,
I guess you nailed me on the whole compliment-your-devs thing. I just looked through old emails and you're right. All I've ever done was complain. I guess all my praise has been going to the wrong devs, huh? Anyway, I'll try to make up for this in the future. I feel terrible.
Yes, reading dev code is a good idea. I did this at an old job where they were using classic ASP and I had no problem understanding it. I borrowed Alex's C# book last year but it's impossible to learn it unless you use it...and I haven't used it (except for those unit tests you helped me write). Perhaps you would enjoy a day of me looking over your shoulder saying "what's that?" as you code...
Meh.. don't feel bad. It's not like I ever commend you guys on anything for which I now feel bad also... even though I don't voice it I do truly appreciate what you guys do with helping to find holes in our code that we never thought of handling making the app more resilient in the process. It's truly insane some of the scenarios you guys think up. Insane in a good way in that I never thought off to do.
This is beginning to feel like Oprah where everyone is crying and hugging and sharing their emotions and crap after being reunited with their long lost 2nd cousin in law twice removed on the step daddy side. (and for the record I don't watch Oprah just so you know -- it's just an analogy)
I'm realy new at software testings (actually i found this blog while studying by myself)
But i am lucky enought to get into a company that make devs e testers work together, so we kinda get friends with each other in low time...
So when i test something that i don't see any bug i just give them a "happy report" ,i think it's nice to say something to them, everyone is happy to be praised sometime....and as friends it's nice to make someone happy =]
but it's somthing more like "hey, ur doing ur job to well....wanna make me lose mine?"