(Warning: this is not a question about a factual problem, rather a subjective discussion about approaches to deal with them. Sorry, I saw the warning - but still hope this is possible here. If not, I'd appreciate pointers to better places. Also I apologize if I seem to jump between various aspects - this is not a finished academic research, but rather a thought process in the making. So I can only show various building blocks and hope that we can we have a discussion which might lead to some learnings...)

Last week I started my weekly report to management with the words "a frustratingly buggy week". And only afterwards I did fully realize that I might be on a journey to find a new approach of thinking about bugs.

I have some early childhood memories about a software-bug: my grandma was working as accountant in a large tea-company that implemented their own accounting software (1970'ish). A few days before going live they discovered severe bugs...and ultimately the lead-dev commmited suicide!

In my job in a software-company I have 2 (or more) roles: I develop software for end-users (based on our flasgship-product) as well as internal use - and I'm also getting involved in the QA of our flagship-product. So I can commit bugs and am affected by them! ;)

My thinking was that a bug is an offensive thing that interrupts productive work and that needs to be fixed quickly so that I does not affect my "rate of output". The fact that I perceive them so harshly may have to do with personal experience as a long-time independent developer (who needed to finish projects to make a living).

But there is another way to see bugs: "Some of us find debugging intellectually stimulating and are perversely attracted to it. "(Dijkstra or Hoare or Wirth?) And I guess the story of Knuth's bug-bounty is well known...

Where do you find yourself on that scale? And what about "corporate culture" dealing with bugs (at your workplaces / in your experience)?

  • Are you not looking as developer only in both views? Commented Jun 9, 2020 at 23:48
  • What's your QA perspective to give better context? Commented Jun 9, 2020 at 23:48
  • Right, I am a developer and am, eh, hmm, getting involved in developing QA's. Not sure what you mean with "perspective".
    – MBaas
    Commented Jun 10, 2020 at 9:22

2 Answers 2


In my role as a SW Tester, I see it like this:

dev environment

I'm happy I've found a bug. I like to contribute to the overall quality, therefore finding bugs makes me feel the product is one step closer to something better.

prod environment

This doesn't make me feel very happy, but it happens from time to time. There's no point stressing too much over it. I, along with the rest of the team, rather look at it pragramitally and try to come up with better processes, so we have fewer production bugs next time.

  • Thanks - interesting. It sure isn't worth getting depressions over bugs - you rather describe how you use it for improvement. Is that process of "trying to come up with better processes" something informal that may happen or not - or is it part of a "debugging processing" in itself?
    – MBaas
    Commented Jun 7, 2020 at 14:12
  • It's true that we try to improve regardless of whether or not there're bugs, so perhaps it's more of a way of doing things in our company. It just becomes more visible, and perhaps urgent, when there's a production bug and we're trying to find out what went wrong.
    – pavelsaman
    Commented Jun 7, 2020 at 14:41

As a QA tester the bug that we perceived is different from management or developer view.

As the earlier comment, about the dev and prod environment is true for all tester. But sometimes when a tester report a bug, the management might decide on how severe the bug will be.

For examples if a tester reported a bug that is not easily found by user or doesn't have large impact on user experience, then it will be put on backlog and will be fix next time. So it is a bug without being stressed by it.

If the bug found is related to the user, then it will be fixed right away and that's why we have branch that called hot fixes for some production bugs that was not found during the testing period. This is a really stressful bug.

Test automation helps a lot in order to reduce redundancy of testing. It also helps us tester to focused vital points of the system (think outside the box scenario that helps to find more difficult bugs that will help to overall quality of the system). Unit Test and Integration Test helps a lot of detecting earlier bugs.

Also, as a tester, I don't believe that there is a bug-free app(not sure about other though). It perceive differently as user gonna used it. Sometimes, the feature might become bug for user too you know :) So it is not as offensive as you think it is, but it might be a bit stressful when it will be reported though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.