At some point I made a mistake which made a certain feature of our app fail. This got mentioned in the next team meeting by QA, but in a really aggressive and threatening way (as in "This simply can't happen!").

It's not a problem for me to admit I made a mistake, or to accept criticism, it can happen to anyone and usually everyone just gets over it and moves on.

My problem is that since that happened (some 3 weeks ago) this QA guy keeps mentioning this mistake at every chance he gets, by directly referring to it, or indirectly (e. g. telling the developer next to me how he trusts his code even without testing it). He also points it out in front of other team members and also uses it as an argument against me whenever we are discussing some future features and he doesn't agree with me.

So far I didn't make any similar mistakes in the past on the project (more than a year). Other team members didn't stress that mistake as much when it happened, they didn't mention it afterwards and everyone is more than satisfied with my performance.

To my defense, the mistake happened because I was alone on it (asked for help, but didn't get any), then at some point it was handed over to another colleague who reported it as finished but it was not, then he left and the feature was again handed over to a third colleague who started refactoring but soon left the project leaving it in half-refactored state, and in the end the whole thing got back to me, in a really bad state. So yeah, I am being blamed partly because of others' mistakes.

Because of constant bring-up of this mistake and the way he communicates it made me anxious. I'm afraid it may leave a wrong impression on my team and managers and it is already hurting my performance because I keep thinking about it and it makes it harder for me to concentrate on my work.

What should I do? I tried to ignore it for some time, but he just doesn't stop. I don't think that escalating it to the managers would help because the project is in its end phase and it's really a bad time for conflicts. We are mostly all external on the project so we don't have common HR to deal with this. I don't think speaking with the QA guy directly would help by any means except make the hostility between us "open and acknowledged".

I am thinking of speaking with the project architect about it privately, who is really friendly, just to make sure that this single mistake I made doesn't overshadow my previous work and performance. I think that knowing that my reputation is not affected and that he doesn't mind the mistake would at least calm me down and help me to ignore the QA guy until the project ends.

  • 2
    Did the QA guy catch it during his testing? or Did the bug deploy to production?
    – djohnson10
    Dec 11, 2017 at 22:31
  • 1
    @JoeStrazzere: I don't trust my own code without testing it!
    – gnasher729
    Dec 11, 2017 at 23:20
  • 3
    @djohnson10: If the bug went into production, that's obviously QA's fault.
    – gnasher729
    Dec 11, 2017 at 23:20
  • 1
    No. QA is not hired to catch all bugs before they go into production.
    – BoboDarph
    Dec 12, 2017 at 13:16
  • 1
    To answer some questions: The project isnt in production yet, we are delivering to the client regulary, its still in development. The issue was found before the delivery and this resulted in a quick fixes done by the senior + we let the client know that this specific feature contains bugs of which we are aware of but "didnt manage to fix in time". It would be enough if he would just stop pointing it out because it makes me feel uncomfortable and makes me look a lot worse now than it actually was at the time it happend.
    – Chapz
    Dec 12, 2017 at 14:39

5 Answers 5


I am a tester. I did QA for 13 years. I met a lot of grade-A A-holes in this line of work. You also met one of them I see.

After reading your story, am I correct to conclude that:

1: You made a mistake when implementing some functionality (for whatever reasons)

2: A QA person you work with spotted that mistake and reported one (or more) defect(s) that you or someone else already fixed or is planning to fix.

3: The QA person uses the defect they reported to bully and belittle you.

4: Their behavior is having negative consequences on your activity.

5: You also believe their behavior to cause your teammates to think less of you.

6: You want to deal with this but are afraid to confront the offender, are unwilling to talk to your employer and would rather discuss it with someone else who has no leverage on co-worker relationships.

I will be skipping over points 1 and 2 because they are of very little importance at this point IMO. If anything could have been done about it, it should have been done before this situation moved to point 3.

Point 3 assumes that someone in your team, who's job is to tell you when you make mistakes, is doing it in a manner you consider unprofessional and bad. The results of their actions leave you feeling bullied and wronged.

Point 4 makes matters worse, as it's not just your feelings that are getting hurt here, but also your productivity (most companies will not care about your feelings as long as you deliver).

The way they chose to act is causing frictions among team members as the person doing the bullying is separating devs into "trustworthy" and "untrustworthy" based on a personal opinion shared only by the QA.

Right before we skip to dealing with the situation, I would like to ask a few questions:

Did you ever question this QA person about the motivation and desired end result of his actions? Is he trying to teach you a lesson? Assert dominance? Is this his way of making sure the mistake you made is not repeated by other team members? What is this guy trying to achieve? Will he tell you his reasons if you ask? If so, why not ask? The answer to his perplexing behavior might be (and usually is) a big misunderstanding.

Now moving on to coping with the situation. The fact remains that, regardless of reasons, a co-worker is impacting negatively on your productivity, workplace happiness and general self-worth. This is bad. And unprofessional. You are correct here. Unfortunately, in environments like yours, where no one gives a damn about how good you are cause you're all externals and therefor replaceable at a moments notice, there's very few proactive things you can do, as a developer to stop this guy from being a jackass. Stakeholders (PM, PO, BA, architects etc) won't give a damn what QA guy thinks about you, they will make up their own minds about your competence. If they just blindly follow QA guy's opinions, you shouldnt give a damn about theirs. Your friend the project architect normally has no saying in who gets fired. So speaking to him to try and get QA guy off your project will most likely solve nothing unless he's close friends with HR or PM/PO.

My first suggestion would be to try and casually confront the QA guy. As stated before, try to find out what his motive and end goal is. Depending on these you could decide to escalate. If he gives you none, I would again try to communicate to him that his behavior is unprofessional and is hurting my ability to deliver, as well as hurting my workplace relationships and feeling of self-worth. At this point any human being capable of empathy will stop and reason if it's worth torturing a fellow human in order to achieve some undisclosed goal. If he doesn't you're most likely dealing with a grade-A A-hole. Or a psycho. Sometimes its hard to tell them apart.

So if that doesn't fix it, escalate. But when escalating, never jump hierarchical steps. And always do it in writing. Stating that you believe your productivity took a dive because this guy is mean to you should get people's attention.

Having been at the receiving end of this type of workspace bulying I can tell you that sometimes this is something you can fix, sometimes it's something the other guy needs to fix, and sometimes you cant work with some people in a team. If you're here, don't blame yourself. Or him. Just walk away.

  • Note that as OP is an external to the company, escalation might be an issue. Not that much of people bothers with externals. Or maybe the path for the escalation might be different (like escalate to his own superior and let him dealing with the customer company).
    – Walfrat
    Dec 12, 2017 at 13:54
  • Again, as a recipient of workspace bullying, it shouldn't matter who pays the guy's checks, the simple fact that he is forced to deal with this harassment on a daily basis should be enough to warrant a serious discussion with the offender at HR department level inside the entity that hired him or has a say in him being part of the project or not. Unfortunately, you are right. I agree that escalation from external contractors are usually less important to hiring companies. If the company he works for treasures themselves on being fair, they will give OP a chance to speak. Even a formal one.
    – BoboDarph
    Dec 12, 2017 at 14:00
  • I am not talking about contractors usually being less important, I am talking about a contractor being fired (it is so easy with them) because "in the eye of the customer company" he was making troubles by simpling reporting it. This kind of unfair thing is common, and of course this is the worst outcome for the OP. This is why I would be very carefull about escalating on the customer side. But I totally agree with the rest of the answer.
    – Walfrat
    Dec 12, 2017 at 14:04
  • That's why I added the "Just walk away" part. You can't help people that don't want your help. Just walk away. Forcing the issue will only cause you more headaches.
    – BoboDarph
    Dec 12, 2017 at 14:09
  • The main reason I am not escalating this is that I dont really see any benefits. The fact that the project is nearing the end, that I am external and he is internal, any type of confrontation would make the relation between us even worse where we would still need to work togeather. Moreover it would put the project lead in a very bad position with the client if our work would suddenly stop because of this. Thanks for your advice, I will talk to a few key people, if they ignore him and didnt change their perspective of me, then I can ignore him knowing that the rest also ignores him.
    – Chapz
    Dec 12, 2017 at 14:54

Fact: Mistakes happen, and create bug. Fact: QA gets paid to find bugs, report them with enough information to fix them, and developers are paid to fix them. Fact: This is not a blame game. It's a professional relationship between QA and development. What this QA guy does is completely unprofessional, and totally unacceptable.

Fact (some people will hate me for this): You are a developer, and he is in QA, because you can develop software, and he can't. You delivered software with bugs, he wouldn't have been able to deliver anything, with or without bugs. Another fact: If you never made any mistakes, he would be out of a job.

There is no need to be anxious about all of this. He has been overstepping the mark tremendously. The next time he mentions it, ask him to replace that broken record. Tell him that you think his behaviour is unprofessional. That he should do his job, and not annoy developers. You can be assured that any single one of your developer colleagues will agree with you.

  • 2
    Starting from the top: Mistakes don't happen. We make them. Mistakes take time and conscious effort to occur. As such they can be a target for root-cause analysis and mitigated. QA doesnt get paid to find bugs. We get paid, just like you do, to help create software people will use. I'm sorry if your vast experience in writing applications hasnt taught you this yet. Reporting them "with enough info to fix them" is an expectation of yours, not a job requirement for QA. Again, something you should have learned by now.
    – BoboDarph
    Dec 12, 2017 at 12:00
  • 1
    Developers, again, are not being paid to fix software defects, they are being paid to produce software of the expected quality to the project stakeholders. When they do not and people find out they did not, they must fix their mistakes as per your job requirement. That being said, I wholeheartedly agree that software development is not a blame game. I, as a QA, do not hate human beings for what they could or could not do. I usually find very specific reasons to hate them for what they have done or tried to do.
    – BoboDarph
    Dec 12, 2017 at 12:06
  • Postulating that the difference between a developer and a tester is that one can write code while the other cannot is another logical fallacy most likely generated by lack of competence in the testing field. When making such judgements of abilities, please refrain from providing your own opinion as an argument. Especially when you lack competence in the field your are judging.
    – BoboDarph
    Dec 12, 2017 at 12:10
  • I often use the "if there weren't any bugs, I'd be out of a job" argument as a joke. No software is free of defects. No amount of time and human resources available at any given time can test even the simplest of programs for all conceivable defects. That is why QA usually resorts to "good enough" testing. In the case of OP, his code was just not good enough to pass whatever checks the tester decided to run. This resulted in a bug report and possibly a fix. The fix itself is more work for the QA. If OP did his job, QA would be a lot less busy.
    – BoboDarph
    Dec 12, 2017 at 12:19
  • 2
    If OP never made any mistakes, the QA would still have a very busy day trying to come up with ways to make sure OP never made any mistakes. Actually, the more stable a piece of software is, the more complex the test scenarios exercising it will become. If all developers were suddenly replaced by infallible AIs, QA would still have a hell of a job making sure that those things dont just claim to be be infallible when comparing them to fallible humans. I will not argue if the QA that OP refers to has made any mistakes here. Just pointing out a few fallacies in your logic.
    – BoboDarph
    Dec 12, 2017 at 12:27

I think some of the problem lies in your own preconceptions around what happens when someone makes a mistake on the job. You believe you are at fault, so you haven't said anything in response. This perhaps applies also to the general culture of your workplace.

Keep this in mind: mistakes are inevitable. At some point or another, a mistake will be made, because people will always make mistakes. Placing blame is self defeating. As people will ALWAYS make mistakes, simply placing blame will not fix the problem. In fact, it will just make the workers afraid to do anything that has any risk for them. This is not a benefitial situation for any workplace.

The problem then is not then that people make mistakes, because like it or not, it will always happen at some point. The real problem is NOT PLANNING FOR THEM. Your workplace should be using process or tools to catch mistakes. Inevitably, the process or tools will fail in some way that a mistake will still make it through. There should be process for that too, which is, hold a postmortem where the problem is discussed, and create a new process or tools to prevent that situation from happening again.

I would suggest bringing up the problem with this person with your manager, and also the idea of having a postmortem to address the original problem. If you do something to address the problem that a mistake got through in the first place, there is a chance this person will stop going on about the mistake.

  • It did not get through. It got caught in QA... That is what QA is for. Dec 12, 2017 at 15:45
 He also points it out in front of other team members and also uses it as an argument against me whenever we are discussing some future features and he doesn't agree with me.

This must be nipped immediately.

"I don't see it that way, remember that bug.." Yes, a piece of code I generated had a bug that you found. Please stop these unprofessional attacks and discuss the facts current at hand.

"I trust your code much more than his". Yes, you have a right to trust whomever you want. Is there anything productive you have to say to this group aloud.

The thing to remember, is to always smile!!! Never get emotional. That is the hardest thing to practice...detachment. He is a bully, and is trying to get noticed. But he must be cut down, somehow, in public.


He's passive aggressive. Confront him and ask what is the problem.

it made me anxious. I'm afraid it may leave a wrong impression on my team and managers and it is already hurting my performance because I keep thinking about it and it makes it harder for me to concentrate on my work.

This is your problem, so there's not much anyone else can do about it.

and also uses it as an argument against me whenever we are discussing some future features and he doesn't agree with me.

You must forcibly point out that one situation has nothing to do with the next. Ask him to make an argument that is on point. If your team and those around don't see his error, there's not much you can do about it. They're obviously limited.

This is in your head. He's being a bully and needs to be put in his place. You know more than he does, so carry that confidence around with you when it comes to confronting him. Ignore the reactions of others. Keep standing up for yourself.

  • He is not passive aggressive. He is aggressive.
    – Alex M
    Jun 17, 2020 at 20:59

You must log in to answer this question.

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