TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: How Should You Feel When You Find a Bug?


A StickyMinds.com Original
Article Picture
How Should You Feel When You Find a Bug?

By Bret Pettichord

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: How you feel about bugs can affect how productive your work is, how you feel about your job, and how others feel about you. In this column, Bret looks at how we respond to finding bugs and how a neutral, professional attitude can make a big difference.


Rally Software
Ordinarily, finding bugs in the software we use is annoying. Even minor bugs can cause delays and interrupt our work. Nowadays, software is sufficiently pervasive and sufficiently buggy that many people encounter software bugs as an everyday occurrence. 
 
This, of course, is the reason professional software testers like us are employed. Our job is to find those pesky bugs before the software is deployed to the end users. If we do a good job, the users will encounter fewer annoyances and feel better about the software. 
 
But how should we testers feel when we find bugs in the software we test? 
 
Happy to Find Fault 
Some testers gloat when finding bugs, especially embarrassing bugs that prove those programmers aren’t so smart after all. These testers may share their findings in office banter, jibing emails, or blaming defect reports that open with “Here’s the latest screw-up.” 
 
This delight is an understandable feeling. Programmers often organize their status hierarchies on the basis of knowledge and technical ability. To gain status, you have to either prove your abilities on their own merit or else tear down the abilities of others. 
 
But this kind of behavior tends to backfire. No one likes to have their mistakes aired in public. Once this trend gets rolling, it’s too easy to make a mistaken call that only invites retribution. And regardless, animosity only makes the testing job more difficult, making programmers less likely to provide the information and cooperation that testers need in order to be effective. 
 
So if you’re feeling gleeful, you’re wise to keep your feelings to yourself. But you might find your job more satisfying if your feelings weren’t so at odds with the programmers you’re working with. 
 
Sad That the Project Is Failing 
Some testers find it depressing when they find lots of bugs. They have a hard time feeling good when they find more and more evidence that things aren’t going according to plan. This reaction is especially likely when project plans provide little time for testing and debugging—and when that time gets squeezed by delays in getting the software into test. With little time available to fix and retest, the testers are truly in the position of providing nothing but bad news. 
 
So these feelings of dismay are understandable. But it is important to know that the tester’s job is to focus on failure, and therefore, they often have an excessively gloomy perception. This is an occupational hazard and one reason why it’s often a mistake to have testers make the go/no-go decision. (But they should have a say in the decision.) 
 
Testers’ feelings of dismay may also be heightened by the realization that the more bugs they find, the more they’ll be expected to work long hours retesting the repairs. The real trap of these feelings is that psychologically people aren’t good at finding things they aren’t expected to find. Testers who are expected to find problems are more likely to find them than testers who are simply expected to “verify that it works.” 
 
So although these feelings may not get in their way of feeling a part of the team, they can contribute to ineffectiveness—eventually leading to job dissatisfaction and the feeling that their purpose is merely to provide scapegoats for the inevitable problems. 
 
Happy to Be Guarding Against Failure 
Other testers are happy upon finding problems because they know that by finding problems early, they are able to help the project stay in touch with reality. The sooner they are found, the sooner they can get fixed. True, the problems might’ve been found sooner, but these testers know that their efforts have allowed them to be found sooner than otherwise. 
 
They report problems in a neutral manner, making clear the impact they’ll have on users without resorting to a blaming attitude. This helps the project team determine how best to handle the problems. They also know that the reason they’ve been hired is to find these bugs. The plans may have been optimistic, but the testers were hired and put on the project specifically to guard against the dangers of exaggerated optimism. 
 
They know that by effectively finding and reporting problems, they earn the respect of programmers and managers. They feel good about the problems they find, because it means they’re being effective in helping the project. 
 
These testers have an attitude that allows them to feel good about their work and also a part of the team. It’s not an easy attitude to maintain consistently, but nonetheless key to their effectiveness. 
 
Feeling Your Feelings 
So, how should you feel when you find a bug? 
 
The truth is that you need to acknowledge whatever feelings you have. If you are annoyed or dismayed, then you get to feel that way. You may, however, need to be diplomatic when sharing your feelings with others. 
 
Ultimately your effectiveness and satisfaction will be best when you can feel good about good work and when you don’t have to hide your feelings from your colleagues.  
 
This requires a mature attitude regarding your role on the team. But it also requires a mature organization that understands the bind in which testers are often caught. No tester is going to be able to feel good about working for an organization that punishes testers for finding too many bugs. 
 
One great way to communicate a mature attitude is to respond to bug reports with “Thanks for the bug report.”  
 
This may start as forced politeness, but eventually everyone gets the idea that reported bugs are better than unreported bugs. Testers can say this in reply to bug reports they get from other team members (even if they are already in the bug database). Managers can say this in reply to reports they get from testers (even if they don’t agree that it’s a bug). Programmers can say this too (even if they’ve already fixed the bug in the most recent build). 
 
What other practices have you seen used to help reinforce positive attitudes regarding the tester’s role on the team?


About the Author
Bret Pettichord is co-author of Lessons Learned in Software Testing with Cem Kaner and James Bach. He edits the Software Testing Hotlist and works as a consultant specializing on software testing and test automation. He is based in Austin, Texas. Contact him at bret@pettichord.com or www.pettichord.com.

Back to Top
 

StickyMinds.com Weekly Column From 12/31/01 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by Vijayaraghavan Sowmya 7/10/2002

Hi Brett I feel John Daughety should be made the Tester of the century, his is the most effective way of testing a product without taking too much pains, his response is one of "All-Time Greats"

 
 
Comment:    
by Surya Dhurjati 1/11/2002

It is a wonderful article detailing the types of Testers. I feel that every Tester must read this to check where he fits in and what others (especially, developers and PMs) think of him/her. It is a fact that whenever I find a bug I feel very happy and find an immediate opportunity to give maximum publicity to it. As a Tester, it is my duty to find bugs …least to say …to ensure my survival. I am paid only to find bugs and certainly not to feel hesitated to put forth my opinion. BUT, at the same time, a tester should not feel over-enthusiastic. Why antagonize the developers by magnifying? You can put forth your point firmly but...Read On

 
 
Comment:    
by sam pro 1/10/2002

Great column. My mantra is: NO VALUE JUDGEMENTS - JUST THE FACTS, MAM. The bug report should clearly state what the problem is, and detail the steps to repeat the problem. Attached screen-prints are great too. I feel good when I find defects (a better name, less negativity) but I never gloat. My how the programmers appreciate that, and return the favor ten-fold. Regards, Sam Pro

 
 
Comment:    
by Graham England 1/8/2002

Great article. I've been into automated software testing for over a decade now and I still ask myself why I get such a kick out of my job, sometimes I find myself racing to work to get back into it (can you believe that?!). I realized that digging deep to find complex bugs that require a sequence of steps to reproduce is a bit like being paid to complete crossword puzzles each day! It's a different challenge with every project and we should feel proud that we help the developers create more successful applications, rather than think of ourselves as a 'spanner in the works' when we find show-stoppers. Have I had too much 'Mountain Dew' or...Read On

Author's Response:
1/8/2002    
I'm glad to hear you find so much joy in your work. I bet your programmers are happy to have someone to figure out the puzzles for them.

 
 
Comment:    
by Tek Wallah 1/5/2002

Testing is an Easter egg hunt. The eggs are there: it's only a question of whether they'll be found in-house or by customers. So why aren't all developers delighted when testers locate bugs? One reason is that QA problem reports usually are tagged with the developer's name, but customer reports are simply sent to Support. In other words, developers may feel that they have 'gotten away' with problem code if it gets into production, but were 'caught in the act' if it's found by QA. It's disheartening that testers have to be reassured that they aren't evil for doing their jobs well.

Author's Response:
1/8/2002    
Great observation. Maybe it's time to remove the developer's names from the bug reports.

 
 
Comment:    
by Arthur Ockwell 1/4/2002

Great article thanks. I have two takes... It is a fundamental "law" of IT that there is always one more bug in the system, therefore the only sucessful test is a test that finds a bug (i.e. only sucessfull tests fail!). Hence the more tests fail the happier a tester should be that they are improving the customer experience once the software is delivered. There is a further emotion, one of complete desperation. In a recent project (i.e. December 2001) I arranged for a four month test window; pure luxury. This soon became 4 weeks. When the final month started the software was not ready to test, and the countdown started, 3 weeks,...Read On

Author's Response:
1/8/2002    
It surely is tough to hold back the i-told-you-so's when the test schedule is crunched and too many bugs that could have been found in testing escaped into the field. I'm glad to hear that you actually noticed which ones you wouldn't have found even with more time. In this case you really weren't given the chance to the protect the project from failure. Maybe next time...

 
 
Comment:    
by Amit Mathur 1/4/2002

It seems to be an eyeopener for both developers and testing team guys. We indeed need to focus on communicating the bugs to achieve our targets and make the work easy. Thanks Bret for another great peace of experience.

 
 
Comment:    
by Giri Uppalapati 1/2/2002

From my past experience, I find that the "Feelings" of the QA Team when they find bugs can be well understood by finding out at what point in the project their active involvement was sought. If the QA team gets involved early on then they are "Happy to Be Guarding Against Failure" else they feel "Happy to Find Fault"

Author's Response:
1/4/2002    
This is an interesting observation. There is no doubt that it's no fun getting involved on a project at a point where we feel we can't really help, but only survey they damage. I am wondering, however, if your observation is an objective or subjective correlation. In other words, is being involved early an objective state or a matter of perception? If our test team has been put on a project late, can we become more effective by finding ways of perceiving this as actually being brought on early? Late compared to when we could have been brought on? Or early compared to what would have happened if they'd waited any longer? Some projects go forth with no test team at all, so we are always earlier than that.

 
 
Comment:    
by John Daughety 1/2/2002

Another good article from Bret where common experiences we typically ignore get some focus and chance for reflection. Since testing can be taken to a very high level of scientific abstraction, it is nice to be reminded that the foundation of good testing involves a small set of basic thinking skills. I have one addition to the set of feelings experienced when finding a bug, a twist on the "sad the project is failing" example: the "this software is not ready to test yet" feeling. When I receive a software build and find several bugs in the first few hours of testing, I think "why has this been handed to me?" Of course, I know the answer...Read On

Author's Response:
1/3/2002    
Thanks for sharing a great story. The smoke tests are a good idea, but i especially like how you were able to use them not just to change to the process but also to change the relationships between the testers and the programmers. Let me add just one point: Sometimes testers also need patience. It may take a while before management realizes that the patterns of failure being found in test need to be addressed by finding ways to improve the code before it gets into testing. Actually they probably realize pretty quickly that something must be done, but it often takes time before enough understanding and motivation come together to make this kind of change happen. Be patient.

 
 
Comment:    
by Dena Laterza 1/2/2002

I sometimes feel sad that the project is not going well when I find serious bugs... but what keeps my attitude positive is when I think to myself that I have executed a great test case. That is what I'm paid to do - think of ways to break the product. This makes be proud of the job that I've done! And I'm just glad I don't have to debug and fix the bugs that I find. Yuck!

Author's Response:
1/3/2002    
Right. And realize that you've been put on the project to guard against failure (unless you really are meant to be the sacrificial scapegoat). People who are expected to fix the bugs they find somehow seem to find fewer bugs, especially of they kind that they don't know how to fix. This is one major reason for independent testing.

 
 
Comment:    
by Danny Faught 1/2/2002

Great topic, Bret. It fits in nicely with and article I recently wrote, "Boom! Celebrating a Successful Test" (in my newsletter at http://www.tejasconsulting.com/newsletter/2001October.html. Testers have to deal with some interesting psychological paradoxes. Overall, testers should be happy when they find a bug. Just not so visibly happy that they make enemies of the developers. :-)

Author's Response:
1/3/2002    
Right, they need to be able to feel happy. But it is best when they don't have to hide their happiness. Happiness wants to be shared. How do we get to the point where the programmers also think: I'm glad Danny found that bug?

 
 
Comment:    
by William Becker 1/2/2002

I agree that this was a great article, and to touch on Tanushree Parial's question about how developers feel when testers find bugs. It is my opinion that developers should look at testers as a compliment to their work, it is the developers program that is being used by consumers or customers, so to have someone to check your work should be considered a benefit to making your work that much better....(01/02/02) Bill Becker

Author's Response:
1/2/2002    
So you could that testers complement the developer's work, even when they aren't complimenting it.

 
 
Comment:    
by Bj Haglind 1/2/2002

As a Sr. SQA Engineer it seems that periodically it would be useful to reread this article as a reminder how doing a good job can catch you up, unawares. The points made are very salient to the experience of Quality Assurance testing. I must say, when I am using software I have purchased, I find it very easy to slip into the SQA role when I encounter a bug. It is interesting that more of the tech support for products is NOT well keyed to the level of detail I can provide as a USER of a production product.

Author's Response:
1/2/2002    
This drives me crazy too. I'll find a bug in personal software, and narrow down the cause and find a reproducible case and the tech support people just presume that my observations are hopelessly muddled without even paying attention to my findings. Argh!

 
 
Comment:    
by Tanushree Parial 1/2/2002

That was a great article and it came at a time when I was starting to fall prey to the second category of feelings you described! But the problem still remains, how do we, the testers, change the way that developers feel when *we* find bugs? I am in a project that is *extremely* hard pressed for time and we have to make weekly interative dleiveries. Since the plan does not have any items under the heading of debugging/bug fixing, every bug logged means that the developers necessarily have to fix it on their own time. It grows into a vicious circle, where they try to patch up the problem somehow, and spawn many other problems, often reopening...Read On

Author's Response:
1/2/2002    
This is a common dynamic that developers can find themselves in. First of all, you need to be sure that you are being neutral in your bug reports. If you say things like "we shouldn't be seeing bugs like this" or "why weren't you more careful" you are going to make the programmers feel worse. But it sounds like you know that already. It sounds like you also know that the real solution is to budget some time for debugging and repair, but then that isn't really within your power. Make sure they know that you're doing your job, and that you aren't the one deciding how they spend their time.

 
 
Comment:    
by Chris DeNardis 1/1/2002

The typical phrase I use at work when I find a bug is “I have had a job satisfying day”. I believe a tester finds themselves more useful by finding bugs, and hopefully serious ones. I like to think that I go in and test to uncover some hole that this is a just one or many bugs the customer will not find. On that note, I would like to take a different approach to what Bret is saying here. What happens when the customers does find a bug? Usually the blame is placed on the test group for not finding the bugs before they were shipped out. What about the usability of the software? This too, the test group, who are the test users, are at...Read On

Author's Response:
1/2/2002    
I like to encourage testers to file bug reports even if they aren't really sure what the correct behavior is. I like your suggestion of thanking the developers for researching them when they turn out not be defects.

 
 
Comment:    
by Robert Lee 1/1/2002

Let me add some perspective to the "Sad That the Project Is Failing" feeling. Designers and developers get this same feeling when the project's details seem to keep expanding. Every project experiences the "growth in unclosed areas" for quite a while before converging on closure. Realize that this feeling of exploding growth of effort is a phase that you get through as you finally round the corner into converging on the target. Every bug or "testing incident" discovered does put you closer to that convergance when it will all come together. Bob Lee

Author's Response:
1/3/2002    
Interesting point.

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


TechExcel, Inc.




STAREAST 


Better Software Conference