Dealing with difficult Developers when introducing QA

I work mostly in start up companies that are scaling up QA. Often teams have worked without QA for a year or two and are loving the freedom, then one day I turn up and start to put some kind of quality processes in place. Most of the time, teams are OK and are very helpful but sometime usually some of the ‘old heads’ can prove to be quite stiff to change.

Multiple ways I have won the battles have been:

  • Involving team members in QA Documentation drafts
  • Getting to know them a bit better before making changes
  • Little and often changes rather than a Big Bang that makes people put the breaks on
  • Showing them insightful metrics to show them their actual quality of their work. Yes you got 30 tickets to done in a sprint but if 60% get rejected you have wasted a lot of time

Whats is everyone’s key tricks when dealing with difficult team members when introducing QA to teams?


People often say that devs don’t like QA but it’s actually just ‘change’
The key role here you need to perform is Change Management, which is probably 75% of any QA his job. I’m a consultant and mostly the problem isn’t ‘doing QA’ it’s just change.

I sweeten them a bit up with pastries in the beginning, get them to love me and then add automated tests to the pipeline and bang! :stuck_out_tongue:

Nah for real, like you mentioned yourself; getting to know them helps. Starting small, not only introducing a ‘new thing’ but also explaining why it’s better the pro’s and cons.
You can always try to say ’ we can try it, if it doesn’t work, we’ll throw it away’


You’re absolutely correct, Ive seen some really good Senior Testers that know a lot about testing struggle with the change management and the QA side of the thing starts to stall. It is defiantly a skill to manage the change as well as selling the QA processes to the team


When it comes to introducing change I highly recommend the model in Esther Derby’s book 7 Rules for Positive, Productive Change.

Prior to reading it, I would always race ahead to the “Let’s get to here cos it’s better” bit. And it definitely helped when I started to use what Esther describes in a chapter: “Honour the Past, Present and People”. Respecting the current paradigm and context made a positive difference.


Definitely a journey we will all take even if we never work in a startup, whenever a brand new product/SKU comes out, the test team get involved a bit late. The trick is to not gatekeep, but to rather seek those friction-reducing changes that get you all to your first public release sooner. Observe and help out in the release and deploy and then iterate over patch releases with small improvements in any release/deploy trouble spots. Also by attending every splint planning and attending the sprint retrospective and having good concrete suggestions to add in the retro.

Practically, that means retesting bug-fixes as soon as possible and closing them, or asking for help to close them, that earns you brownie points for sure.


Adding to this, I think it’s important to spend a lot of time assessing what’s currently being done, and then figure out all the little things that will help foster a culture of quality.

The job isn’t to make sure all the code works; it’s to help the team be confident that their code works and keeps working. Fostering that culture of quality usually means lots of small tweaks, where the team eventually owns quality, as opposed to relying upon a third-party to verify their product.


Ha, as usual @ernie has said it more clearly. Give devs confidence that bugs won’t escape. It lets the whole team mover faster when unknowns slowly get nailed down and removed.


A good way to introduce yourself and QA measures would be to find a few bugs to prove your worth. Look at previous bugs, are there patterns? Then look for these patterns. Try to fit yourself into the existing processes (one can always widen the processes afterwards if they are lacking), try to be stealthy when fitting you and your QA measures in. At the same time, try to take part in as many team meetings as possible, retros, dailys etc. And most of all: be a positive, helpful colleague, testers are usually considered a bit of a nuisance, the guys with the checklists. So prove them wrong.


I’m interested here in two things.

  1. Why are things being set to Done before QA has taken place? A better approach would surely be include any QA in the ticket itself, therefore nothing is being ‘rejected’ just ‘reworked’ as part of the sprint.

  2. What is the organisation like in terms of ‘blame’? Does someone get it in the neck every time something is ‘rejected’ or do people act like adults? (Sorry, previous experience of working in an organisation where every time we found a defect the senior manager would start yelling at people!


I think what @testgoblin highlights here

Is the main reason that the QA person needs to be sure to get invited to the sprint planning meeting, the grooming session, and the retro. If the devs are not doing those 3 things by one name or another, they are not agile yet, and you are better off talking to the release manager and the PO than talking to the devs about process attitude. We all know that in agile a ticket is not “done” until it is with the “customer”, the customer could be the ops-team, but if the customer is the tester, then it’s not agile. Bring out this chestnut . It’s almost worth an entire retro half hour, to get this defined and agreed in your team.

Once you get invited to a retro…and don’t get me started, retros are the first meeting that gets cancelled during release closedown, and it’s the most toxic thing a team lead can allow to happen, but anyway… the day before the retro write down the TOP 3 things that you did not like and one thing you did like. On a notepad somewhere. Then take one of the things that went badly and write down a suggestion to change and resolve it. Be sure to make your wording as positive, as possible while not pulling your punches. Take that notepad to the retro.


Thanks for this interesting information!

I think it is really time to leave the old era behind. With the speed of how software changes, it is ridiculous to have a development team that is stiff to accept quality assurance, especially as quality is not a one-man-band responsibility but a team’s responsibility, not to say cross-domain responsibility.
I know it might happen even more often to come up to such a fellow developer though.
I don’t have specific tips and tricks for dealing with such, except just doing my job, being my best and showing them results. No better motivation than just showing something gets better in time, despite the pain of discussion and all work around found bugs. :slight_smile:
Be persistent! Be communicative and collaborative. Don’t take it personal. Simple as that.
Keep in mind also that in order to achieve anything as a QA person in charge, you should also have the management support and clear view what kind of and how much resource the company is ready to invest in the quality.