Last week on Dev Tester, we discussed a couple of ways to help you guide a team of developers and testers towards test automation. Among the tips included in the article were to take the lead with testing, start with something small to show the power of testing, and help others learn better testing habits by teaching new skills and reviewing their work. With time and patience, you'll eventually show the value of automated testing and have others get into the mix.
That article has a few personal stories from my career that helped me get my teammates on board with a consistent testing practice. While I managed to successfully lead many developers and testers on the path of test automation, I don't have a perfect record. Far from it — plenty of times, I've fallen flat on my face. I didn't have much luck with some organizations and teams, and my efforts fell short of the target.
Reflecting on those times when I didn't have the success I'd hope for, I could spot a couple of similar situations where I could have certainly done better with my approach each time. This week, I wanted to cover three of the most frequent issues I ran into when trying to guide a team towards test automation. Hopefully, these scenarios and stories will help you avoid the same roadblocks that I stumbled upon.
Mistake #1: Forcing testing on the team without explanation
As with anything in life, trying to impose your will on others to do something without giving them good reasons for it is a sure-fire way to fail. No matter how well-intentioned your ideas are, people won't follow them if they don't fully understand the how and the why behind your thoughts. It might even make people build a severe dislike for your ideas and have them forever resist what you want to accomplish, even if it'll yield excellent results in the long run.
The most common mistake people make when introducing test automation is that they paint a picture about how much better the organization will become, but they don't explain how to get there or why it matters. The lack of clarity will make others fill in the blanks in their minds since you didn't provide it for them. More often than not, it ends up with them thinking that test automation is more work for them without any guarantees for the benefits you mentioned and won't be worth spending the time and energy. That's where the resistance comes into the picture, stopping your efforts dead in their tracks.
It's not a surprise that I'm a massive advocate of test automation and want as many teams to reap the benefits of a well-made automated test suite for their work. But sometimes, that excitement comes out the wrong way. I have set it upon myself to get other team members to build an automated test suite more than once, and I began placing unofficial "processes" in our workflow like rejecting code changes without tests and pushing too hard to add time for scheduling tests in our sprints.
The problem with these forceful changes was that I never took the time to explain why I was attempting to improve our testing flow, nor how it would make our codebase better. Instead of explaining and taking things at a slower pace to get everyone acclimated to these changes, I brute-forced my way into it, and the team hated me for it. I was utterly oblivious to that in one former workplace until my boss pulled me aside and let me know everyone was complaining about me.
Now that many years have passed, I realize that I could have prevented all that rage and resentment towards me if I had set clear boundaries and intentions before I even began to implement any new changes. If I had taken the time to clearly explain the benefits of automated testing and how we could collaborate as a unified team, I'm sure most of my co-workers would have been receptive to the idea. Instead, it often ended with no testing and a bruised reputation amongst my peers.
Mistake #2: Not having a long-term plan
If you avoid the previous mistake and take the time to clearly explain the value of test automation and how to start, you'll have an excellent chance at bringing your team towards a more test-driven process. However, these actions still don't guarantee success. Even if everyone in your organization is receptive to the idea of improving your automated testing workflow, you'll still need to know where you're going. If you don't have a long-term plan for your testing efforts, you'll likely won't get very far on your journey.
With new efforts like this, there's always a burst of excitement and enthusiasm at the start. The possibilities of making everyone's work and the overall team better can produce the push needed to begin the journey. But if you don't have any plans outside of getting started, this initial surge will wear down fast. You need to set some longer goals to keep everyone moving forward. Otherwise, your efforts may wither and die quicker than you might expect.
I've lost count of how many teams I've been a part of where we started hot with automated testing in the first few weeks, only for the process to slow down to a crawl. Sometimes it's a rapid decline; other times, our efforts slowly deteriorated to the point where no one bothered doing anything related to test automation anymore. The real danger of reaching this point is that it becomes almost impossible to get back on track once your first attempt fizzles. Few people will want to get on board with test automation again because "we already tried and it didn't work."
Looking back, the common denominator in the failure to maintain consistency with our testing efforts is that we never planned out how to carry the momentum towards the future. We only focused on short-term objectives. For example, we'd plan a sprint to set up continuous integration or write our first batch of automated tests but never set any processes to use these to our advantage. Once we completed work in that sprint, no one knew what to do next. It became a directionless grind, and without any good reasons for spending time on test automation, the team gave up on it.
The best way to prevent this mistake from happening is to have a clearly defined roadmap that can guide towards future milestones to hit. Some examples could be to reduce the number of regressions after deploying to production or reach a certain amount of coverage on high business value sections of the codebase. With a plan in place, your organization will have something to aim towards, keeping everyone motivated after the honeymoon period inevitably phases out.
Mistake #3: Not having buy-in from the higher-ups
The ideal situation for guiding a team towards test automation is when everyone involved in the project and building the tests agrees with the process. It would undoubtedly make your intentions flow much more effortless. However, in most organizations, you'll find yourself with some team members who aren't totally on board with automated testing for some reason or another. That's fine — not everyone has to agree with the process entirely. But you do need to have specific stakeholders on board with the idea if you want to be successful. Mainly, you'll need the support of the higher-ups running the project.
The issue is that if the higher-ups — team leads, managers, the CTO, and so on — don't want to do test automation, you'll find yourself with an impossible mountain to climb. These roles are the main pieces of the organizational puzzle that can give you the time and space to work on improving the organization's testing practices. Without their explicit support and backing, you'll find yourself hitting a brick wall with your efforts sooner rather than later.
It might seem far-fetched that someone like a tech lead or the head of technology in your organization doesn't want to do any kind of test automation. After all, it's their job to help the team deliver the best work they can, and test automation plays a crucial role in achieving high-quality output. But team and organization leaders are usually under tons of external pressure to produce results. In this constant state of urgency, they view anything other than tangible results as a waste of time. Sadly, testing is one of the first things thrown out the window in these cases.
If you have a boss who doesn't want to spend time on test automation, you can attempt to get something going on your own time. But be aware that this can backfire since you're technically going against your superiors. I've done this once at a small startup where my boss felt that automated testing was a waste of time, and it almost got me fired.
In an effort to change my boss's mind about test automation, I spent a few nights of my own time setting up an automated test suite for our codebase. I showed it to him when I had some decent coverage of our project. He proceeded to give the most exasperated sigh I've ever heard and told me that the next time I want to do something on my own time, I should take on some of the backlog instead of "pointless tests". Needless to say, I moved on from that job shortly after this exchange.
Overcoming any objections about test automation from the higher-ups in your company is not an easy feat to pull off. You can have meetings and try to convince them about the benefits and how it will make the team more productive and, in turn, make them look better. A good way is to negotiate the time to start with something small and demonstrate some value. But as the story above proves, this isn't guaranteed to work in all scenarios. If you still encounter strong resistance even after you explain the "why" and "how" and defining a long-term plan, there's likely little you can do to change their minds, and you might be better off looking for greener pastures.
Summary
Last week's article on Dev Tester mentioned some ways to help you guide your team towards better test automation practices. The tips in that piece reveal a few methods that have helped me achieve my goal of getting others on board with testing. But it hasn't always been successful, and I've fallen flat on my face plenty of times when trying to help others with their testing processes.
This article shows some of the frequent mistakes that developers and testers can make when they're attempting to bolster their organization's automated testing practices. Trying to force others to follow your lead towards testing without explaining how and why usually leads them to run in the opposite direction. Not having a solid plan on what to do after the initial testing push will likely cause your efforts to decay over time. Finally, you can't do much without the backing of the team leads and your bosses, even if everyone else is on board.
If you find yourself struggling to get your team on board with test automation, check if you're slipping into one of these mistakes. There's a good chance you're running into something similar and can get back on track if you realize what's not helping your cause. Sometimes, knowing what not to do can be more important than knowing what to do.
What other mistakes have you dealt with when trying to guide others towards test automation? Help others avoid the same issues by leaving your stories in the comments below!
