6

I am working as a software qualify assurance engineer and partially due to my work, a bug managed to get to our production code.

  • Our customer service team has reported back this issue to us on Slack.

I am thinking if I should publicly own up this mistake and come up front to take responsibilities.

  • Our company has a no-blame culture, which means no one blames anyone else. But I think I need to admit it is my fault that this bug has escaped to our customers.

If I should come up front, how far should I go?

Thanks

Improve this question
4
  • Congratulations! You found a new way to break the system. This is why we test. Were it not for your valuable efforts, think how many more bugs would slip through. Now write a test for it and move on. Regarding admission, I agree with @Bill Horvath.
    – Justin
    Commented Mar 14, 2019 at 9:06
  • Maybe the title could be improved by removing the "in public" bit? At the moment, it reads like if OP makes a mistake at work then they should tell a random passer-by.
    – dvniel
    Commented Mar 14, 2019 at 11:52
  • What would you hope to gain by "owning" your mistake? Would doing so have any meaningful impact on the way the work resulting from the bug is handled in your team? Is identifying "ownership" of bugs (in the sense of attributing cause, as you're doing) part of your team's official process?
    – dwizum
    Commented Mar 14, 2019 at 13:45
  • Don't worry too much about mistakes like this. Just own up to them and learn from them. Your not likely to lose your job for a mistake like that. Not unless your the person that was supposed to make sure those 737 Max 8s stay in the air. That person might be in big trouble.
    – Trevor
    Commented Mar 14, 2019 at 17:30

6 Answers 6

Reset to default
19

If you're working in an Agile shop, and you're part of a Scrum Team (or similar arrangement), the team has collective accountability for this kind of thing. You should certainly own up to the mistake with the team - That's how the team maintains individual accountability. However, as far as the rest of the business is concerned, the team owns the mistakes, because no one person is likely to have been the sole source of a problem. (You didn't write the buggy code, did you?)

Improve this answer
2
  • 2
    Correct, the blame is with the entire system. Not just the person who wrote the buggy code, but the reviewer who didn't notice it, the testers who didn't find it before accepting the release, the acceptance test team that didn't find it either.
    – jwenting
    Commented Mar 14, 2019 at 5:48
  • 2
    Scrum or not, I agree with this.
    – Justin
    Commented Mar 14, 2019 at 9:06
10

You don't need to make a big thing of it, but admitting you should have caught it is no bad thing. The best way to respond to this (internally or otherwise) is to admit responsibility and show you've tried to ensure it won't happen again:

My bad on this one I'm afraid - slipped through our testing nets as the x testing script doesn't cover y which caused the bug. I'm in the process of updating that script now so this shouldn't slip through in future iterations, and I'm in conversation with Bob who may also be able to catch this ahead of time via a unit test.

That sort of a response isn't overly apologetic, but to the point and gives the impression that you "get stuff done".

Improve this answer
2
  • 2
    Exactly, what people more care about it how the issue will be avoided in the future.
    – Gregory Currie
    Commented Mar 14, 2019 at 8:55
  • 2
    +1 for this. There's no dishonour in missing a bug - it happens to everyone at some point. Telling them what you've learnt from it and how it'll be prevented in future can make you look good. Personally, I have a lot of respect for people who hold their hands up and own their mistakes.
    – dvniel
    Commented Mar 14, 2019 at 11:47
5

Taking responsibility for your mistakes shows a level of maturity that is good to have, both personally and professionally. It is definitely a characteristic that stands out more with consistent use, so don't just do it today and expect consistent returns for years to come. Yes, own your mistakes. No blame means don't point fingers. It means human mistakes can and should be understood. Not that you aren't supposed to acknowledge that you personally goofed.

That is internally. Customer facing personnel should handle statements that go out to the public consumer. There is more to consider there. The face of the company, legal liability in admitting fault, etc...

Improve this answer
3

Yes, please own your mistake. A no-blame culture doesn't mean you can't take responsibility for your own mistakes.

I work for a company which also has a "no-blame" culture. This implies that if something bad happens, the first thing we do is "mitigate the effects". Then we fix the cause. And afterwards, we write a document explaining what went wrong, how did we notice it went wrong, which steps were taken, and offer suggestions how to avoid that in the future. And we make this document available to everyone (we've an internal website to search those documents).

But while we don't blame (notice that all steps describe above are focused on "what happened" not on "who's responsible"), we still value owning up to mistakes. The person who made the mistake is going to be one of the more valuable people to fix it -- they're the one most familiar with the code. Owning but not blaming also helps in getting bugs fixed as soon as possible.

Of course, that doesn't imply you need to make a big show out of it. Just say "I made a mistake. I'm working on a fix right now".

Improve this answer
2

Before you get too wound up about your mistake, please keep one thing in mind: The only people who never make mistakes are the people who never do any work. Good QA can reduce the number of defects which come to the attention of the customers, but even the best QA can not guarantee a 0% defect rate. That means a few defects slipping through is to be expected. This is a normal thing in the IT industry.

So before you come forward and apologize, consider if you actually did something which makes you responsible. Did you not use the budget and resources you were allocated? Did you not follow the agreed upon processes? Did you not test all the use-cases you explicitly committed to test? If none of these is the case, then you did the best you could and have no reason to blame yourself.

If you decide that you need to point out that you indeed deserve blame, do not focus on self punishment. Focus on what you are going to do different to prevent this mistake from happening again in the future.

Improve this answer
1

No there is no mistake to own.

No disrespect but you seem pretty novice and naive. Bugs getting their ways in production are part of the life. I'm sure your product have a few out there (maybe less critical, again no disrespect. It's just the way it is). No need to need to own anything. Why would the dev be less likely to "own" the mistake? After all he wrote the code (I'm a dev myself).

I don't know maybe it's something super obvious and it have been caught before the release, in this case you and the dev(s) are as much at fault here.

I'm all in to own mistake when there was one but in a case of a bug getting it's way into production is not one of them. In any complex system it's practically impossible to cover all cases. Proving a negative is really hard, that's what you do when you test the product. The question is not "Does this product is 100% defect free?" it's more "Are we confident about the quality of the work done by the team (80-99% depending on the team, product, etc)

Improve this answer
2
  • I think what you mean to say is that it's okay to make the mistake. He's in QA and says he missed a bug. It's a mistake.
    – b15
    Commented Mar 14, 2019 at 20:28
  • @b15 like I said, if it's truly something that should have been caught the dev miss it so the team "failed" on this bug
    – Rémi
    Commented Mar 15, 2019 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .