How Do You Feel When You Find Bugs?

I saw this tweet from

And thought I’d ask more of the community how they feel when they find bugs.

For me, it depends on the bug. You know that feeling you have when you’re using something that it’s just not quite right and the developer feels the same but you just can’t put your finger on why? Then you find that bug hidden in there causing that feeling and you’re both so excited that you found it so that things feel right.

The other side of that is when you’ve seen someone pour days or even weeks of effort into getting something to work and you have it for 5 minutes and you find a bug. I feel gutted in those situations. There’s that incredibly grim time where you call the developer and you see their face or they type their reply and you know you’ve just deflated them completely.

How do you feel when you find bugs?


I think there has to be some context here. Finding something that wasn’t considered up to this point in development for me is a nice feeling. I’ve contributed to an improvement in the product. So Quality Amelioration rather than Assurance.

This made me think that this could be affected by your personal view maybe. If I think, here’s a ‘finished’ thing to test then I might get sad that it isn’t finished. But if I think, here’s a thing in development and I’ve an opportunity to improve it in lots of ways then I might be happier to find something. Anyway, what do I know :man_shrugging: :smile:


Finding an obvious problem in something is depressing. It means someone didn’t do their due diligence - although it may not be a case of substandard work from a developer. I’ve found it’s more likely to be that the developer isn’t familiar with the code and unknowingly landed on one of the many hidden complexities that cause problems - and that is something that should have been handled by internal training or product owners explicitly spelling out as many of the possible minefields as they can.

Tracking down an annoying edge-case or intermittent issue is fun and rewarding for me. That’s a situation where I’m playing detective and figuring out why some bizarrely specific problem is occurring, and tracking it down means I’ve saved everyone else a lot of annoyance and potential problems.

So, ultimately, it depends on the bug.


I love finding bugs, because they trigger my “thrill finding something unexpected”. I hate when I find out the cause of the bug is something that I think could/should have been prevented, because they trigger my anxiety about “doing something that people didn’t expect and they could get defensive about and then I feel I did something wrong”. Which I then have an internal fight against, empathy <-> rationality, which can lead to exhaustion and depression, or at least a talk with my psychologist :slight_smile: .


When I find a bug and the developer says something like, “How did you even think to do that?” feels really good. Those moments are when I feel like I have contributed to the product in a very constructive way. The same feeling happens when a fix is suggested and it just doesn’t feel right so I push harder to understand the cause of the issue and we find the root cause is actually a rather large problem. Those moment validate my career choice.

When I find many very obvious bugs like “this button doesn’t go to the right page” feel draining because I know the developer missed something little and they kick themselves for it. In those moments I usually stop and go back to our requirements and mocks to see if the issue could have been vagueness on what the UI should do. If that is the case, I will stop testing and talk to the developer to see if we need to go through the section together and make sure we both made the assumptions, if we didn’t then we bring in the business to clarify. I have found going that route can help the whole team work together toward a better understanding of the product instead of just focusing on the plethora of bugs If the documentation is very clear I like to ask the dev if something maybe wasn’t checked in that should be before I continue.


Depends on which kind of bug.

  1. Obvious bug - unhappy.
  2. Bug because something was missed, but not obvious - happy.
  3. Bug because of edge case - happy.
  4. Requirements bug - very happy.
  5. Bug reported by users/other teams - sad.

Too many 1 means change job. Many 2, 3, 4 means I might be good. Too many 5 means I should improve and/or go to the team of the reporter with the best bugs :).

Finally, major bug in other company or competitor’s product - Overjoyed.


This reminds me of the “Testers’s satisfaction curve”. A bit of a tongue-in-cheek, but I think there is some truth in it. It is our job to point out things that are not correct in a system. If you don’t find much or anything you might not feel much contentment (maybe even doubting yourself if you’re good enough at your job). With the more things you manage to highlight, the more your (job-) satisfaction grows.
Till you reach a point where you find too many bugs and then your enjoyment wanes…


As a web developer, I like when a bug is found - if that results in a bug report which contains detailed instructions on how to reproduce the bug.

This kind of bug report provides insight into how the app is being used. It provides a fresh perspective and opens the door for improvements beyond the actual bug fix.

A bug which prompts a fresh look at the app is actually a good thing in my opinion. It’s when people stop looking for (or logging) bugs, because they don’t want to know, that really bothers me.


@pmichielsen -good unless your manager thinks that bugs found is a main measure of tester.

I think this is all of us:



Ah yes, but if that is the case, a whole different conversation needs to happen :man_facepalming:

1 Like

I love it, but have learned to conceal my joy in a more palatable, team-working-friendly way.

I remember once finding a bug in production, in smoke testing actually, and kind of punching the air. My director of development was beside me, and called me into his office for a “talking to”. He was an ex-dev.

By the end of that conversation he understood why it was A Good Thing to have testers who are motivated and excited to find bugs, and devs who are motivated and excited (well, motivated) to prevent them.

Same director eventually promoted me to lead so I guess it works out :smiley:


I find a sense of relief sometimes when I find a bug, relief that something is found before production. I rarely feel overjoyed, even though finding bugs is so important.

But also sometimes frustration, despair and other negative feelings.

It really depends on context and how it is communicated.

My biggest faux pas was when I was testing an early online version of Colin McRae rally and I complained about a bug over the headset ‘who implemented this?’, and of course the developer was in the session wasn’t he? face palm


Awesome? That is a part of my job after all and I’m happy that I caught it before the official release. I agree with @raghu on this one, on the classification :grin:


Wow. I find this so true to life :sweat_smile:


Depends on the context.

Sometimes, I notice something odd and completely separate from what I am looking at. It could be something completely unexpected, or unanticipated behavior. I investigate and find more details about the issue. This is like a treasure hunt, or solving a complicated puzzle. Finding bugs this way feels like an achievement, because of how hidden they are.

If I am testing something specific, a new feature for example, and I find an issue then I feel a little disappointed. I want the application to be high quality and I feel bad when there is something that impacts the quality. Also, this is something a developer has worked hard on, so I know not to celebrate an error they’ve made. There is also a feeling of dread that I will have to test it again when the developer has fixed the bug. Another thing here, because I know the change has been made, it doesn’t feel like much of an achievement when I find a bug there. We know there has been change, so we know that there is likely to be a bug here.


To be honest, I get a lot of the bug-hunt euphoria, but always with the hanging dread, is this a bug my team will have to take time out to fix? Will I have to verify the fix. I do like finding bugs, mainly because that means the customer did not find them (or I hope not.) Verifying the fix is satisfying, but not as much as it should be, there is no fanfare for hotfix releases.

I do struggle with bug dread when it’s a bug I don’t understand, because that often means another team has to fix it and I may get dragged into their domain. Which is a contrary way to approach bugs, because bugs that lie between domains or teams are pretty common. But you always feel like you are going out in the “bug-desert” a bit far from your “watering hole” for these kinds of bug. Security is another such class of bugs I dread a little.


I love/feel great when:

  • I gather conclusive evidence and details a bug can be easily understood and fixed
  • A bug is caught and fixed before production, phew!

I feel awful finding a bug that:

  • We choose not to prioritize and fix, urg
  • I can’t quite figure out the root cause and it’s intermittent so I cannot be confident the fix worked

So as others have said, context important!


I’d like to see a thread on how do you feel when a customer reports a bug. Is it the same feelings that have been spoken about here? Or more feelings of dread that the team missed something? Or maybe it’s a positive thing where the team reacts in a lesson learned way.


Excellent idea @melissafisher! Do you want to create one? :grin: