Facing Resistance Introducing Dedicated QA

By Ruslan Desyatnikov, is the CEO & Founder of QA Mentor

Rulan_Desyatnikov1030

Regardless of how many years you’ve been in quality assurance, at some point you were the new QA person on the block, either solo or as part of a new team. A newly created QA team has the daunting task of implementing new processes and strategies to companies that have worked without quality assurance for a while. In some cases, this can lead to culture clashes with development teams, sales personnel, and managers alike, but for the purposes of this article we’re going to focus on the potential pushback from development teams.

Don’t Touch My Stuff        

A developer may occasionally feel possessive about their tools, their environments, or even their code. When QA is introduced, new people are suddenly coming and wanting access to code, demanding some control of environments, and requesting notes and other documentation. No matter how much you support the efforts of quality assurance, having someone come in and start messing with your stuff and questioning your efforts may put you on the defensive.

Who Needs QA

A development team that has been releasing applications and patches without dedicated quality assurance may feel as though they don’t need QA. After all, they’ve been getting along just fine without it, right?  For some, it could be difficult to convince them that dedicated QA will add value to their work. 

Anarchy Rules

Perhaps up until now, the development team has been able to fly by the seat of their pants and refresh, create, and destroy environments as they see fit. They developed at the required speed, released when they wanted, and answered to no one other than their manager. Bringing QA into the loop can mean stricter processes, additional documentation, and someone else to answer to. Having to ask others if they can refresh a database or push out a new build is an additional step that some teams may not be used to, and could add some resentment.

We’re Here to Help

QA individuals and teams can help mitigate these and other concerns by including themselves as part of the development team instead of some external ‘oversight committee’ there to find fault in everyone and everything.  By framing their requests and efforts as a means of aiding the team they are a part of, they can help stave offpotential defensiveness.

Show your new teammates all the good that QA can do by helping them see that QA is there to make the developers look great by aiding the team in releasing better quality software. Create an initiative to help developers with API testing, begin performance testing, and give them some of the functional automated tests to use as unit tests.  Show them how their job can be made easier with QA there, freeing them up to do what they love to do best: develop.

If the pushback is documentation related, compromise may be necessary. Notorious for documenting and asking the same of others, QA teams can show flexibility with all of that additional paperwork and limit it to just what’s necessary.  QA pros familiar with Agile will already be used to this concept, so it will come naturally for them.

Be patient and implement changes incrementally. Let new teammates adapt to one change before tossing on another.  Any new team that comes in and changes everything at once is bound to meet with rabid resistance. So, take it one step at a time, starting with the things that will have the most positive (and hopefully immediate) impact.

A little empathy can go a long way. All in all, the best way to integrate QA into a reluctant development team is to put yourself in their shoes. Encourage communication and allow them to express their concerns freely, and then listen to them.  Be flexible and show them all the good that QA can do.