Return to Answer

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• Patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• Communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?

• Be aware that some devs will take criticism of their code very personally. I myself often struggle with this when I am writing code. It's easy to say 'divorce your personal emotions from the code', but can be much harder to actually do. So some devs will take the criticism personally and want to 'check' it against another source instead of just accepting what they feel is like a criticism of them from you.

• Talking about criticisms... Remember that you are double-checking their work in your role. Think of them as double-checking your quality work as a helpful second set of eyes.

Finally,

Evaluate the situation

If all the above do not help... maybe it's time to move - and ask the right questions in the interview to make sure it is better at the new place.

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• Patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• Communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?

• Be aware that some devs will take criticism of their code very personally. I myself often struggle with this when I am writing code. It's easy to say 'divorce your personal emotions from the code', but can be much harder to actually do as a professional who does care about the quality of your work. So some devs will take the criticism personally and want to 'check' it against another source instead of just accepting what they feel is like a criticism of them from you.

• Talking about criticisms... Remember that you are double-checking their work in your role. Think of them as double-checking your quality work as a helpful second set of eyes.

Finally,

Evaluate the situation

If all the above do not help... maybe it's time to move - and ask the right questions in the interview to make sure it is better at the new place.

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• this is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• Patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• Communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?

• Be aware that some devs will take criticism of their code very personally. I myself often struggle with this when I am writing code. It's easy to say 'divorce your personal emotions from the code', but can be much harder to actually do. So some devs will take the criticism personally and want to 'check' it against another source instead of just accepting what they feel is like a criticism of them from you.

• Talking about criticisms... Remember that you are double-checking their work in your role. Think of them as double-checking your quality work as a helpful second set of eyes.

Finally,

Evaluate the situation

If all the above do not help... maybe it's time to move - and ask the right questions in the interview to make sure it is better at the new place.

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice:

• this is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (may not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communciation with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• this is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?