1

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.

  • 8
    This would be good to ask in The Workplace. – user4548 Jan 29 at 15:40
  • Might I suggest that you post this question in sqa.stackexchange.com? – Laura Jan 29 at 21:54
  • 1
    Possible duplicate of How to not be "this annoying nitpicking Quality Engineer"? – Astralbee Jan 30 at 9:47
  • 2
    This is almost identical to your previous question which got loads of answers but you didn't accept any of them. If you didn't get the answer you want why don't you go back and revise your original question? – Astralbee Jan 30 at 9:50
  • 1
    @Noon Quite a few of the answers, including one I gave, addressed the issues of introducing change in your environment. You did not accept any of the answers given so we have to assume you didn't get the answer you wanted. Are you hoping this question will generate different responses? – Astralbee Jan 30 at 9:56
3

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.

  • I agree that the open discussion is the better way to go. However, I can't help but remark that some teams/developers/companies suffer from a toxic change-resistant environment, where opening a discussion topic leads to conflict, which leads to any intended change being shelved because it creates animosity. I'd suggest to tailor the approach to the environment. – Flater Feb 6 at 9:20
3

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
  • Unfortunately, I don't think this approach will overcome the inertia of the devs. I've never worked in a shop where a QA person has any hope of dictating any development standards, especially a 'noob'. Right, wrong or indifferent, that's just how it is. – Johns-305 Jan 29 at 23:55
  • @Johns-305 I'm not sure I would describe it as "inertia". Development process is usually hashed out in a series of meetings, some formal, some "hallway meetings", some friendly, some contentious. It's not inertia to come to an agreement and stick to it unless there's good reason to change. – DaveG Jan 30 at 1:58
  • Hi Aserre, do you have experience using this approach? If so, could you edit to include a little of your background? Answers here should be backed up with expertise (based on the details here it sounds like you have some!), but spelling it out is helpful for readers to compare quality and relevance of answers for their own situation. – Em C Jan 30 at 15:25
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.