Have a question for me? See my About Me page and send me an email.
Based on this post and question, I am considering starting an online book club where we email our insights based on going through a book. If you are interested, please let me know by emailing me (tim [at] developerautomation.com) or leaving a comment on this post.
A reader recently asked me:
I’m currently working for a company that has very little developer automated testing coverage. We’ve implemented a testing framework and started doing some testing. I believe much greater coverage in testing would lead to higher quality code and ultimately a faster product delivery and a better product. However despite this work on infrastructure the missing piece seems to be in getting everyone to get behind the idea of automation, testing and it’s purpose. What do you believe are the best steps for forwarding this agenda? What strategies / tactics could we employ to push for a more test driven approach in a company that has traditionally done very little developer-led testing?
I’ve got to say… this question hits home very dearly to me. I’ve had similar questions:
- How can I get my team to start using unit tests?
- What can we do to start testing without hardware?
- How can I convince… [feel in the blank]
I will be completely up front and say that I do NOT have the solution. I do have some recommendations. I feel like this all comes down to the culture you have at your company. To that effect, I will recommend a book that was recommended to me (and that I’m now currently reading):
So without further ado, let’s talk about culture.
Changing a Company’s Culture
They Never Taught Us About This…
All throughout high school and college, we are taught over and over about programming concepts. We even have those teamwork exercises where you usually have at least one person on the team that does absolutely nothing. Rather than address how to deal with these people (who also exist at the workplace!), we generally ignore them. Whereas this can work at the university level, it is toxic in a workplace environment. Everybody knows ‘that person’ that never really does anything or isn’t very technically competent. It’s like the big elephant in the room.
Once you get to a certain level of technical ability, soft skills matter so, so, so much more. Even if you don’t have the title of some leadership position at your company, you have to be able to lead to some extent.
Fostering Relationships within Your Team
Being able to influence your team or drive their direction starts with your personal relationship with them.
- Do you ever ask about their day?
- Do you do things outside of work?
- Do you ever have lunch together?
No, these aren’t required, but it is much easier to tell help a teammate through something or get them to change their behavior when you have that relationship there. This doesn’t just include your team, but management as well. They may need to know what initiatives you are trying to drive… maybe, but it depends on the situation. If you can get upper management to endorse your initiative, it’s going to be easier to get the team on board.
Every person on your team is going to have their own agenda…
- I just want a paycheck
- We just need to get this done no matter how ugly it is
- Solving bugs is just a normal part of life
- We must have the highest quality to help us deliver faster and debug less
What is their agenda? Can you fit your initiative into helping them achieve their goals?
Once you have that relationship and know how automated testing can help your developers, you can start to build support for what you are doing. You may have a developer be willing to write one test. Or it may be that they install the framework to run the tests. Whatever it may be, encourage that small step. If possible, make automated tests part of the acceptance criteria for being done (if you are the product owner/manager… and if not, try to convince that person for this to be the new normal).
Here’s an example from my own work environment:
- The biggest issue we have is delivering on time
- We don’t have time to develop infrastructure to make us faster
So how can I help the team use more testing to get us faster?
- Make the barrier to entry very low
- Show that it can make us faster
Unfortunately, I work in a very hardware-focused company that doesn’t put a whole lot of emphasis on software. When I have conversations with management with ideas that I have, they think it is a good idea. However, I don’t think they grasp the entire idea or just how big a difference software quality can make. And we are much more concerned with the next project rather than improving as a whole.
So I need to talk to the development team.
One of the biggest issues we have is not having hardware. To that end, I have attempted to use Docker containers as a mock for hardware devices. The more and more I can develop this mock environment, the more our team can work even without the hardware we are testing. This is a method to change our behavior can get our team to thinking more about automation and code quality.
In general, though, it’s a very slow process. Trying to get out of firefighting mode (where we are always rushing to get the latest thing out) versus focusing on the upfront work to make us faster is a culture change we don’t have yet. In order to get there, we probably need…
- Training on using the tools we use on our team
- Training on unit testing/testing with mocks
- Mindshift change so it’s ‘ok’ to work on non-project related things (infrastructure) every now and then. That might mean not elaborating on what we are doing behind the scenes at times.
- Better team culture – it’s gotten better than it has been, but we still don’t work together as a team very well (we don’t have a shared team space, for example)
Right now I am working on the infrastructure. Training will come later… but I still need to work on hammering home my points over and over about how we need to focus more on quality. And making it clear how focusing on this will address every other developer/manager’s wants and needs.
To sum it up, my advice would be…
- Develop relationships with people on your team. Know what drives them.
- Relate how automated testing will help them (you won’t have to debug as much/you won’t get calls when you’re off work about a bug in the code)
- Encourage baby steps and build off them.
As I said, this is an area that I am not very experienced in and definitely could be better. To that end, I’m going to be reading through Debugging Teams: Better Productivity through Collaboration to help myself and others with issues like these. Want to join me? Leave a comment here or email me: tim [at] developerautomation.com.