How to introduce change in a process while avoiding conflict?

Question

I'm a 23-years-old Q&A engineer who recently started a job in a company who never had Q&A before.

The other day, I was talking with my chief and the chiefs of the development team and told them that I wanted to ask the devs to always write unit test when fixing a bug. This is something that, I believe, is a pretty regular practice and all the chiefs thought it was a good idea.

At the beginning of the daily stand-up meeting, I went ahead and told the dev team:

Maybe you already do it, but it would be good if you write tests for each bug you correct.

The team is composed of several devs (7 I think) and two of them freak out and were absolutely against the idea ("what if...?").

I didn't think this was such a big deal (after all, they are supposed to write unit test when programming, but I don't know if they are really doing it) and I think I'm up against what is called "resistance to change".

So, how could I have present this change in a positive light and such that it wouldn't have raised so much defensiveness?

Note and clarifications

• "Write tests for each bug you correct" -> When saying this, I hadn't had time to clarify if I was meaning "every bug fix however trivial" or more of a general rule. So, what I actually meant have no importance here since they had already reacted. (but, if you must know, I wasn't and still isn't decided on that point).

• I know they have some unit test and, for having written unit tests before, adding one is usually quick (unless you have to do something you haven't done before but this shouldn't happen that often).

• They are suppose to have time to write test in their current workload. If they don't, then Manager is definitively okay to give them more time to do that.

• The lead-in I use before the announcement: "Hey, I have an announcement". (So, definitively not a great lead-in).

• Someone asked me how this question wasn't a duplicate of my previous one. They are both similar indeed. But my previous answer was more about dealing with one person in a one-on-one situation when this one is more about global change and group interaction. Also, here I don't care about looking nitpicking, I just want people to agree with the changes.

_{This probably doesn't matter but this is happening in France.}

Answer 1

I understand your enthusiasm in your new job, but announcing such a big change in a standup meeting is definitely the wrong time. Instead, I'd suggest to have a meeting with the devs, where you introduce yourself and your role. (They didn't have QA before, so they might have no or the wrong idea of what to expect.)

Rather than a one-sided presentation, I'd treat this meeting as an opportunity for you to also learn something about your coworkers. How do they approach testing their features? Are there code reviews? And yes, are they writing unit tests?

You need to be open about what you learn in this meeting. Maybe the current test coverage is much lower than you'd expect. Maybe half the team has no idea how to write unit tests and may require training.

Once you've got a better understanding of the team, you can explain how adding unit tests would help them waste less time with debugging. There will be counter-arguments to that, and I'd advise you to take them seriously.

Work with the devs, rather than against them. If you ask them, I'm sure they can name bugs that reappear frustratingly often or bugs that took days to track down. These are easy targets that allow you to make a very strong case for adding tests that will end up saving time.

Rather than starting with a blanket rule that, from now on, all bug fixes need to be followed up by a corresponding unit test, you might have greater chances to succeed by starting with common and high priority bugs. Once the devs see the benefits of writing unit tests, it might even become a habit.

I also strongly agree with @Aserre that you need to look out for and support any potential allies. As a developer who recently learned about test automation, I've since been the driving force in my team to increase our test coverage. Our QA department has been incredibly helpful in guiding me through the process and answering all my questions, which in turn allowed me to support my team when they started writing their own tests.

Answer 2

I think the introduction to the subject was a bit too abrupt.

In general, when you have people resistant to change, barging in with a very disruptive idea (they basically heard : "you now have to lose half a day writing tests every time you add a new feature") will lead to immediate outcry as a defence mechanism.

What I would suggest is to take it slow, with incremental progress leading from their current state to where you want to lead them.

• Check the state of their current workflow before pushing the issue further.
  • Do they have tests at all ? Do they automate them in a pipeline ? Is it only unit tests, or do they have integration tests as well ?
• Define your own goals. What would be the criterion to call it a successful transformation ?
  • Would a few unit tests be enough or do you want them to fully embrace TDD and test automation ?
• Present them with with incremental steps to improve their workflow.
  • Maybe they don't need to spend the next sprint refactoring their code to implement the tests? Maybe a few days here and there for an extended period of time would be enough ? Maybe you could provide them with templates or frameworks that would help them implementing the tests on new features ?
• When presenting each new step, make a point to show the short/mid/long term benefits of your solution. If you can, try to use objective and measurable arguments.
  • Telling a developper "spending 1 hour developing your tests today will save you 1 day in debugging 6 month later" is a sane argument people should be able to hear
  • Do not hesitate to use existing studies / blog posts by experts / feedback from other teams
• If some people inside the team are willing / excited about the change, use them to your advantage. In a team, changes lead by a peer is almost always more welcomed than some policy pushed by an external person
• Set up regular team meetings to collect feedback, and try to act upon it. If only a few portion of the team keeps being resistant to the changes you push, try setting up individual meetings
  • If you feel you don't have the legitimity to do so, you can rely on your hierarchy to handle the meetings, especially if they seem to be backing up your ideas

Answer 3

In this scenario, you can't, because you've already noted that "two of them freak out".

All you likely can do is minimize the conflict. Also, don't focus on "Unit Tests", see below. Make it about an actual, verifiable problem.

The Interpersonal Skill to use is Making Someone Think It's Their Idea.

The best way to do this is start by presenting the desired result as a noble goal, such as reducing reducing rejected fixes, then laying out a case using verifiable and reproducible evidence. Pro Tip: the DEVS will not respond well to feelings or assumptions.

This will work best if you can frame it as benefiting them somehow, even better if it benefits only them. For instance...

I see 20% of team time is spent on things kicked back from QA, if we cut that in half, hey, that could mean an extra hour of Fortnite :)

Then, you can use some leading questions to, hopefully, get them to agree internally on better ways to test a build.

Is there a testing pattern you guys think would help with this?

Be prepared to accept whatever offer they make which may or may not be Unit Tests. This is step one of what may be, well, just one or ten. As long as you can prove a benefit, they should be willing to do more.

---

How they're thinking:

If someone were to ask me to implement Unit Tests, my response would be "No. We're not doing that."

Why? Because the Unit Test fad ended like 5+ years ago.

Why? Because it was a lot of work for little gain. I've seen at most 2 cases where Unit Test were 'correctly' implemented and neither produced any meaningful results. Meaning, the bugs had been and still were combinations of internal and external points that a Unit Test wouldn't uncover. They're better off spending their time building a test suite based on a set of inputs and outputs that can be run as part of the build process and tests the app naturally. Meaning, Unit Tests are a side effect. This is how it used to be before "Unit Test" became a thing.