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.
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
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.
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 .
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.
Bug because something was missed, but not obvious - happy.
Bug because of edge case - happy.
Requirements bug - very happy.
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.
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
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 @anon68517856 on this one, on the classification
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â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.
.
