How to Get Developers in Your Team to Contribute to Your Test Automation
Maybe you are a tester who is currently trying to encourage the developers in your team to contribute more to the test automation framework?
Maybe you are a quality coach and you’d like to get test automation into your definition of done?
Maybe you are an engineering manager and you want to see the developers in your team make an active effort to write more tests?
If any of the above apply to you, or the title caught your attention, then read on.
I’ve often been asked how to get developers to contribute (more) to the test automation framework and my answer depends on their situation.
However, I have noticed a few patterns.
In this blog post, I’ll share some advice on how to get developers in your team to contribute to your test automation.
What Do I Mean by Contribute?
Before we get ahead of ourselves, I want to explicitly define what I mean by “contribute to the test automation” and what I am tackling in this blog post.
I mean primarily the following: Developers add tests for the features/changes they implement (it is part of their definition of done).
While developers can also contribute in other ways, such as by coming up with ideas on the design of the test automation framework and creating mocks and stubs, this isn’t the focus of this blog post.
Change Is Hard
In my blog post Implementing Change, I share how implementing change is hard.
What you are trying to achieve here is difficult.
You are trying to change the way things are currently done.
Brace yourself for this and be patient.
This will take time.
Also note that when it comes to change, change itself can be stressful for people.
As stated in Jitesh Gosai’s talk at Öredev:
“Your brain can’t tell the difference between a bear or a change to your team’s WoW.”
It also helps to share with the team why you want the developers to contribute to the test automation, and then what will things actually look like once you are in the new reality.
Some possible reasons you can choose to share include:
- You don’t have enough testers to write the test automation, so you need the developers to also contribute
- There have been too many regression bugs making it to prod
- You want your tester(s)to focus on other tasks instead of test automation (share which tasks these are).
Now, not all of the above reasons are restricted to why you want to encourage your developers to contribute to test automation. For example: The regression bugs reason is one that about having a test automation suite in general, not as to who is contributing to it.
Take Time to Understand Why Things are the Way They Are
Talk to people.
Listen.
If you want developers in your team to contribute to the test automation, you need to understand why they are not currently doing it.
Also be prepared to not be explicitly told why they are not doing it.
Bear in mind that actions speak louder than words.
For example: If your team says they really care about quality, but then all of the developers’ effort is going towards adding features, then this tells me that the reality is probably one or more of the following:
- The team cares more about adding features than quality (I’m not saying they don’t care quality, just that they care about something else more)
- The team believes that it is solely the tester(s) responsibility to contribute to the test automation
- The team has aggressive timelines and the developers do not have time to contribute to the test automation. (And thus with the first reason, adding features is prioritised)
Common Pushback You May Receive (and how to respond)
“Our developers are too busy”
I’m going to assume you are in one of the following situations:
- You have an overworked test automation engineer who is currently doing the test automation but also is expected to test each new release, co-ordinate testing across different teams etc.
- You don’t have any test automation yet, but the team is starting to feel the effects of the lack of it.
Your team has probably prioritised adding features.
I would start off with doing two things:
- Talk to the Developer Lead and Backlog Owner in your team about your concerns
- Introduce a Way of Working like stated in my blog post How to Make Quality a Team Effort
There may be concerns about having developers contribute to test automation because it could slow down feature delivery. Your Backlog Owner/Product Owner could be concerned how this impacts their deliverables, what they have promised to their stakeholders.
Which is a fair concern.
But if you are in one of the above stated situations, I would then ask which is more important (in the long-term):
- Features that are delivered in a high-quality state
- A team that has a balanced, healthy workload
- Lots and lots of shiny new features
It’s a case of prioritisation.
You would also need to show the team how to contribute to the test automation and then check in on how things are going during this transition period.
Yes we’ll do it when we get the time
When will this be?
Get a concrete commitment on this.
I admit, there are certain times in teams that aren’t great for introducing new things/changes.
So check to see exactly when will be a good time.
Then follow up.
The follow-up here is key. People may be counting on you forgetting and not actually following through with this, so don’t drop the ball here.
This isn’t the developers’ responsibility
First thing I would check here is the roles and responsibilities at your company.
Is it actually not the developers’ responsibility?
Or have people just worked with the assumption that a person with “test” or “quality” in their job title will do all the test automation work?)
If it is formally part of the developers’ responsibility, then reminding the team of that can be helpful. I wouldn’t do that in a meeting in front of everyone but would probably have a small discussion with the Product Manager (or equivalent) and the Developer Lead in your team.
If this responsibility isn’t in the job description of your company, then I would ask why it’s not (and if this needs to be the case for people to actually contribute to the test automation).
Final Comments
Aside from the blog posts below, I also recommend you check out Anne-Marie Charrett’s Quality Coach book.
In this book she gives a lot of insight into how teams work and operate, that could also be useful for you if you are going on this journey.