Recently on Reddit, there was a new post in the r/softwaretesting subreddit titled How to lightly guide my team towards practicing TDD? The poster of the thread works at an organization that didn’t have any frontend testing and is attempting to improve their automated test coverage. While the poster started with some basic implementation, they’re running into a roadblock where the team isn’t on the same page. According to the poster, the team “seems afraid to try to learn how testing works”, and “the manager is hesitant, and isn’t enforcing testing at all.”
I recently wrote about my experiences taking a project with no automated testing to over 1,300 automated tests, so I can empathize with the Reddit poster’s dilemma. Once you experience the benefits of test automation, it’s challenging to work on a project with no testing. However, the previous article differs from the poster’s situation since I didn’t receive any pushback from others due to being the only person working on the project.
Still, I completely understand how frustrating this situation is. I’ve worked on teams of multiple software developers and testers where I was the only one interested in bolstering our test automation efforts, trying my best to get others on board. I was successful with some teams and not so successful with others. These attempts helped me understand how to better communicate with others to come to a shared understanding of the value of automated testing. I’ve also covered this topic previously on Dev Tester.
If you’re in the same situation as the poster from the Reddit thread, it may seem like you’re in for a long battle, but it doesn’t have to be that way. Here are a few real-life stories that you can use to help you get your teammates on board with testing.
Starting slow and easy
Every effort has to start from something. The key to success, though, is to begin with something small and simple and build from there. A frequent misstep when trying to get started with test automation is the urge to do too much, too fast. For instance, a team member wants to start with testing by adding different unit, API, end-to-end testing tools simultaneously, along with a full-blown continuous integration environment on day one. This urgency leads to people feeling confused and bossed around, which will push them away from what you want to accomplish.
At a previous job, I had spent weeks trying to convince my fellow software developers to begin adding more automated testing into the mix. Our programming stack had built-in testing tools, but no one used them. My first approach was drawing up a rather complex diagram explaining how I envisioned the testing workflow, covering all kinds of tests, tooling, and changes to our development and testing processes. It was a lot of information for anyone to digest, and I got nowhere with my efforts.
Instead of cramming as much as possible from the get-go, a better alternative is to do one thing at a time and work on making it easy to use before moving to the next thing. I refined my approach by asking the team lead for some time to add continuous integration to see how it worked for us. I set a CI system up with some simple alerts to some key team members. Less than a week later, someone committed some code that had a bug, which our tiny test suite I was cobbling together caught instantly. It provided an “aha!” moment for the team, and they began to see the benefits of automated testing.
Setting up one thing and making it dead-simple for the rest of the team to execute tests locally can yield tremendous benefits. That way, the team can have a low barrier to entry, especially if they’re not used to building an automated test suite. If everything goes well, build upon it with other complementary tools and services to further bolster your workflow. As the adage goes, Rome wasn’t built in a day. You can’t expect your team’s attitude towards test automation to change overnight. One small step can become the gateway to a long-term effort where everyone agrees that it will help produce higher quality work.
Be the first to show how it’s done
When someone hesitates to accept any idea, whether at work or in life, it usually boils down to that person not fully understanding why they should be open to it. With test automation, it’s no different. If someone doesn’t understand why the extra effort of writing tests is beneficial to them, they won’t try. It might be part of the issue with the poster from Reddit since they wrote, “I just know we’ll see gains tenfold when we all use it.” It’s hard to convince someone that they’ll see such a massive boost to their productivity without concrete evidence. Developers and testers experienced in test automation know the benefits already, but unless you do a good job explaining it, your call for help will fall on deaf ears.
In my experience, the best way to explain is by doing and demonstrating the value first-hand. The way to do that with test automation is to begin building a test suite. If you’re the only person interested in automated testing on your team, it means you’ll be the person in charge of getting the initial efforts started, likely on your own. If you’re lucky, you may be able to convince the team lead to give you some time to focus on this task for a sprint or two. More often than not, though, you’ll probably have to find the time outside of your daily work to do it.
The previous story about setting up continuous integration and demonstrating its usefulness is an excellent example of “show and tell”. I’ve also been part of many teams where I’ve made it my mission to set up a good test automation base for the rest of the group. Some bosses understood the value of this work and provided the time and space to attack the problem. This situation is admittedly rare, unfortunately. After all, if the team doesn’t practice any form of consistent testing, there’s a good chance it’s because the higher-ups don’t understand the value of testing. In those cases, I’ve sacrificed some of my personal time to get something started, which paid off down the road.
The purpose of focusing on an initial push towards test automation is to have something that shows the benefits clearly. If you choose the right tests to automate and the systems to set up, you’ll find something that points to visible improvement — catching a bug that snuck through, faster regression testing, and so on. These efforts serve as the origin of demonstrating why automated tests will increase trust and eventually deliver better quality products.
Take the time for code reviews
Organizations with a code review workflow provide an invaluable opportunity to get others involved with automated testing. Code reviews intend to help everyone on the team maintain and improve the health of the codebase. Checking that any new change to the codebase has adequate test coverage covers those bases, as automated tests boost the quality of any codebase and keep quality high.
Take the time to involve yourself as much as possible in code reviews among your team. When you notice new changes that would benefit from automated tests, bring them up in the discussion and guide the team towards adding that coverage to the test suite. For example, you can mention that their changes require too much work to test manually, so automated tests can help reduce the team’s QA time. As long as you provide good reasons why writing tests are helpful and show them how it will improve their work, most team members will be open to accepting your comments.
My biggest wins when it comes to expanding my team’s testing abilities have been thanks to frequent code reviews. If I spot an opportunity for a developer to include an automated test to cover a change in the codebase I’m working with, I’ll point out why it would make their work more stable in the long run. If it’s a simple test, I’ll write it for them in the comments so they can understand better. After a while, I always notice a steady increase in test cases from everyone on the team.
This constant reviewing has given me the reputation of being “the test guy” among developers in all of my jobs. One of my proudest moments was when a former co-worker took the time to draw my “portrait” on a whiteboard in the office to show what I often did during my workdays:
As a developer, I understand how it may feel like you don’t have time to review other people’s code. However, if you’re in a position where you have the experience to teach others about anything, you have a responsibility in your workplace to help as much as you can. There’s no excuse, especially if you’re one of the most senior members of your organization. The point for you to jump into code reviews isn’t to force people to write tests — that’ll make you the most unpopular person on your team quickly. The key is to let them know how tests can benefit the work they just did. Everyone wants to do their best work and keep it that way, and test automation will lead them there.
Teach those who aren’t used to testing
Some developers and testers haven’t had the opportunity to work on test automation and may not have the experience needed to contribute. They may want to help, but since they feel they can’t, they’ll shy away from your efforts and may come off as disinterested. Some team members can even feel embarrassed to ask for help. Sometimes all they need is someone to guide them in the beginning to learn how to get started. Who’s better than you to be that guide?
One of the most effective ways to help others gain knowledge and experience is pair programming. An experienced developer or tester can spend a few hours with a less-experienced team member and tackle some automated tests. Pair programming isn’t limited to in-person interactions, either. Tools like Visual Studio Live Share lets people in different parts of the world collaborate in real-time on the same codebase. Pairing is different from teaching because you can get your work done while the other party gets a chance to learn and contribute quickly in a low-stress environment — it’s a win-win situation.
At a recent job, our team had a few testers who only performed manual, exploratory testing. The organization expressed an interest in test automation, so they wanted to transition some manual testers to write automated tests. Some developers scheduled pair programming sessions with a few interested testers. In one case, I helped a tester from Peru make the jump into JavaScript programming so he could also improve our project’s automated testing stack. We tackled a few real-world tasks for the project together, and he picked up on everything a lot quicker than if he had attempted to learn on his own. He eventually became a full-fledged Software Developer In Test, thanks in part to these pair programming sessions.
Pair programming isn’t the only way to share your knowledge. Some organizations do activities like lunch-hour presentations where team members teach something new to others. Internal documentation can also go a long way in educating when done well and kept up to date. Sharing videos or blogs that have helpful information also helps. Whatever method you choose, teaching will help others understand the benefits of testing and, in many cases, grant them a newfound interest in the topic.
Summary
It’s not easy to get a team of testers and developers on board with the idea of test automation, especially if they’ve worked on projects for a long time without it. Before you give up, thinking that old habits die hard and you can’t do anything to change their minds, you can pull off a few moves to begin turning the tide in your favor. This article shows that it is possible to shift their mindset, see the benefits of automated testing, and contribute to the cause.
You have some options that can help you chip away at any preconceived notions about testing. Starting with something small can help you quickly demonstrate the benefits of test automation. If you take the lead on creating the work, you’ll set the example for others to follow. Take the time to review new code changes and teach those less experienced than you to help them produce results that the entire organization can benefit from.
These are just a handful of potential choices you can start making today if you’re serious about improving the quality of the entire organization’s output. Whatever you choose, a recurring theme in all of these stories is that you must clearly demonstrate the value of testing. If others can’t see why they should spend the time on test automation, you’ll find yourself running up against a wall you can’t knock down.
As with most situations, there’s no “one-size-fits-all” solution to the issue. Some of these paths can actually backfire and make others shy away from testing altogether. I’ve had my fair share of failures. Stay tuned, as next week I’ll go through a few stories that show you can’t win them all.
What tactics have you used to introduce test automation to other members of your team or in organizations without any testing in place? Leave your stories in the comments section below so others can benefit from your experiences!
