Addressing dev team's resistance to solutions suggested by QA engineer?

Question

I've joined this company as a Engineer in Test to create a CI, automated testing, etc. My problem is that when I identify problems and tell the developers how to fix them, they ignore me and are quite hostile. How can I get them to listen to my input? I want us to be able to work better as a team. Right now I feel trapped as the QA guy that nobody respects.

Some details of what happened:

1. When I've found that web application has an issue because our front-ender doesn't know the difference between GET and POST, I've explained him the issue in several lines. He said that he doesn't get it, so I gave him the link to SO about exactly the same issue with dozen of nice and comprehensive answers, he just refused to read it and started to do everything just the opposite to my advices. Often shouting on me while other coworkers around but not bosses.
   I told my boss #1 that he doesn't want to cooperate -- got no answer.
2. We had a meeting with all the team involved and came up with branch naming, task tracker and deploy workflow, but the same front-end guy is continuously violating it deploying bugs and even making the GitLab to 503 by using ridiculous branch names.
   I asked boss #1 again and again to explain him that we should cooperate -- no answer.
3. When I've found that back-end code has a large number of reinvented wheels, I've pointed back-ender that there are high-order reducing functions in his language stdlib and that they should be used instead of for-each-break copypasting. He yelled on me, got up from the table and insanely gesticulating shouted that I "should not teach him because he is coding in this company for ~7 years" and that for some reason makes him right.
   Boss #2 was walking around and reported the boss #1 that something happened.

Immediately boss #1 (still working remotely for few more months) made a video call to me and told me that he doesn't know what happened and doesn't actually want to know -- told me that whatever happened, it is my fault and, quote: "no matter who is right, the friendship is more important than competence".

Around a month has passed since then -- all those guys still don't listen to me, write crappy code, learn nothing and have nothing to teach me. Again and again they are fighting with issues that would not happen if they listened to me when I warn them. But even if I have more years of coding experience and know more programming languages than they do in sum, since I'm working here only for few months and in position of Engineer in Test that means for them that they shouldn't listen to me.

Answer 1

My problem is that when I identify problems and tell the developers how to fix them

I think you are exceeding the scope of your position, and I'm not surprised at the reaction you get. Your job is not to tell developers how to fix things. I've been in this business a long time, and I have never had a QA person tell me how to write code. But then I've never worked with QA people who look at code. That is outside the scope of QA.

When you come to a developer talking about how they should be using high-order reducing functions and so forth, I can tell you exactly what is running through their head: "If you are so good at coding, then why aren't you coding?" Your whole post has an attitude like that. If you are so good and they are so bad, then why are you still working there?

The primary role of QA is, like you said, to identify problems. You do that through testing and analysis. Any information you can add that would help in solving the problem is always good. But be careful about proposing solutions. Remember, your job is to identify problems, not solutions. All developers expect from QA is as much information as possible to solve a problem. If you know how to fix it, then by all means, provide details. But if all you have is an opinion, then make it clear it is an opinion, not a directive. Write "I think it's because XYZ needs a token on every request" or "I suspect we are omitting the token."

Answer 2

Addressing dev team's resistance to solutions suggested by QA engineer?

As an "Engineer in Test" you probably have more coding skills than most QA, especially in your current work environment based on your question. You need coding skills to do automated testing, and that gives you the false impression that those skills are accepted and respected by the ones doing development.

However, by making suggestions on how to fix the problems, you are overstepping your professional boundaries. You have limited information and insight into the complete development process. The guys writing the code have to be responsible for solutions, so let them do their jobs.

A non-technical analogy I like to use is this: if you hire a roofer to replace your roof, you will ask questions and observe him to feel comfortable that he's doing a good job. But if you get on the roof and start telling the roofer how he could be "doing things better" or whatever, you have gone too far and are probably going to make your roofer mad. Get off the roof and stop telling the guy what to do.

Focus on building your systems and identifying developer bugs. Let them identify and select solutions to the problems you identify.

Answer 3

I think you need to split your communications with development in two:

• Formal reports of detected bugs.
• Informal suggestions from you to the developers for how to fix or prevent them, and informal suggestions from the developers to you for how to test the software.

You should try to build a good working relationship with the developers. That may have been made harder by how you started out, so back off for a few months. Start by asking their advice: "I think we should be doing more stress testing of component X. What sort of workload is likely to overload it? Any difficult areas that need extra testing?", Try to build a relationship in which the giving and taking of advice becomes normal and unimportant.

Once you have that relationship, try casually mentioning that you think a particular cluster of test failures might be fixable as a group by some design change.

Answer 4

I want to first start by saying that I work in a very similar field with almost similar objectives: IT Audit. If I understand you correctly, you are frustrated because you feel that others are not heeding your advice and your boss is not being supportive of you by insisting on relationships over competence.

When you want people to listen to you and take your feedback seriously, you want first to tell them how listening to you will benefit them in their work. In your case, the benefit will be fewer bugs and better functioning code that is more likely to meet business objectives. Continuously writing poor code and refusing to improve when given chance demonstrates contempt, aggression, and almost arrogance in a sense, as in they know better. If continued, such behavior will almost guarantee termination due to incompetence and not being able to work well with others.

I suggest that you assume the positive - that these developers are not trying to be hostile out of spite. Most likely they are not understanding Why you want them to change. Assume people are rational, that as much as they may not want to cooperate, they won't jeopardize their own job due to this conflict. Discuss with these developers when all parties are calm and explain your thinking process - Why you want them to change as you do and how they will benefit from doing so

Your boss is also being unreasonable here by insisting on relationships over competence. I wholly disagree. Your work reflects on your boss - either poorly or well. When your boss wrings his hands of all accountability, he is putting his own job at risk. By not recognizing competence and value added through process improvement is what he and his team members (yourself among them) will ultimately be judged upon, he is showing remarkably poor judgement. The situation is unpleasant, but burying one's head in the sand does not make the problem go away.

Your work serves as a control over the work of others and you have to accept that due to this fact - There will always be people who dislike you. Take the high road and do not view the feedback as a personal assault, no matter how unpleasant. Grow a thicker skin and learn not to react to the hostility / unprofessionalism of others - In the long run, this practice will serve you well.

Answer 5

I agree with this answer about making clear separation between reports of problems (your job) and informal suggestions to address them. To this I add one further approach: ask questions.

I'm a technical writer, often responsible for figuring out the corner cases in an interface before documenting because, as we all know, no spec is ever 100% complete. Sometimes I discover behavior that is, shall we say, not entirely desirable -- it's counter-intuitive, or it's inconsistent, or it's expensive. I've done pretty well in my career by explaining what I thought would happen and what I saw instead, saying why I care (if not obvious from context), sharing any speculations I have about cause, and asking for input or help. You can make a suggestion or plant a seed without telling somebody what to do, after all.

Here's an example of what I mean:

I was doing some security testing. I thought that a client request for data from the service would be rejected if the user isn't authorized, but I was able to read data anyway. Specifically, I started a client, read some data, revoked that user's authorization at the server, and then read some more data, and that worked. Do we not check on each call? If we're caching it, do we specify how long between rechecks, or is that left unspecified? I want to make sure I explain this clearly in the administration documentation.

Suppose the answer is that authorization state is cached at the server and the developer doesn't want to make any further guarantees. To continue the conversation:

Thanks; I understand. So if a server administrator wants to make sure a revocation takes effect immediately, because maybe it's a high-risk situation, is there some way he can flush the cache? Or does he need to drop the session and make the client reconnect?

What we've done here is to describe the user's problem and think out loud about ways, with the software as it is, that he can solve it. A developer who thought that a little lag in updating authorization isn't a big deal might think again if the response is to restart a client session -- maybe that's too heavy-weight. Or maybe that's perfectly fine, and you'll learn that client sessions are meant to be short and ephemeral and oft-renewed, in which case you've learned something about the design.

You and the developer are peers with different specialties. Neither of you should be dictating to the other how to do his job, but you should both be open to sharing, learning, and working together to solve your customers' problems.

Answer 6

As has been suggested, the best strategy may be stepped back and containing your eagerness to tell everyone how to fix things, and instead focusing on identifying, documenting and testing fixes to the issues.

Also in this particular case, the workplace culture might prioritize seniority and division of labor over competence. Earning respect in such a setting might be a long-term process and uphill battle, requiring more time and effort than would have been needed in a different type of workplace. It sounds like management is complicit, valuing status quo over adaptation and change.

I am wondering if this pattern would have changed if the business need drove the speed of bug fixes, i.e. if the bugs were causing obvious and measurable delays and customer complaints. This would be difficult to address until the incentives change, but that is likely outside of your control. If you believe this signals dysfunction at current workplace, and continues to demotivate you without hope for reversal of trend, to the point of quitting, it may be time to consider other employment options.

However, there are a number of changes to your behavior that seem worth trying before dismissing the current situation as beyond repair. I would encourage you to first take a step back and review your own approach to this process, and heed the advice about avoiding giving too much advice regarding the fixes unless solicited by the dev team.