Despite the recent push towards effective testing practices and the use of test automation across the software development world, many organizations still aren't quite there yet. More companies have invested their time and money to bolster their testing processes and improve the delivery of their products. Still, plenty of workplaces haven't taken any steps yet. Whether it's because these companies are content with their existing methods or they're okay with not diving into automation yet, you'll find plenty of software companies without solid automated testing practices in place.
As a tester, you might be in the fortunate position of working somewhere that embraces test automation and has established a robust testing environment. However, it seems like the more likely scenario is being employed someplace that could use some help in the testing department. Every so often, I stumble upon a post or tweet online by a fellow tester asking for advice on introducing test automation at their workplace.
You've probably found yourself in this situation, where there's no clear path towards testing or test automation on the company's roadmap. It could be that you recently accepted a new job at one of these places, or you have been working at a company for a few months or years while building up your automation skills. Regardless of the reason, you'll probably have the urge to kick-start test automation as soon as possible. So you walk up to your manager or team lead and excitedly let them know about your desire to implement better test automation practices.
Unfortunately, it's not uncommon to have your request struck down almost instantly with one of the following replies:
"It'll slow us down - we don't have time for that!"
"It's too much work on our already-full workload."
"We don't have the budget to allow towards test automation at this time."
As testers, we always want to increase our work quality and make our processes better, from development to testing to deployment. We expect our teammates and the organization to share a similar vision, at least partially. So why do we often receive these negative reasons when trying to improve everyone's work?
The mistake testers make when bringing up test automation
The first thought that crosses our minds as testers when our attempts get shot down is that the team or organization doesn't care about testing. It might be true in some places, where QA, testing, and test automation are barely a blip on the product development radar. However, most of the time, the issue isn't that your workplace or manager doesn't care about it. Often, the reason is that they don't understand the value that testing brings to the table.
Plenty of companies may have a brief understanding that test automation is something useful for them. But most won't have a clear idea about how that usefulness translates into the company's daily workflow. These misunderstandings worsen when team members mention the topic without providing details about how these practices will help the organization in the short and long term. This lack of clarity ends with management viewing test automation as yet another layer of work they need to deal with, not to mention an additional expense without an indication of its benefits.
Most testers who try to kick-start test automation practices for their projects tend to repeat some of the same mistakes when making their case:
- They never clearly explain what test automation does or how it fits into the company's existing workflows.
- They make their arguments for testing without having a solid plan, merely stating "we should work on automating tests" with no follow-up.
- They only talk about the benefits it will bring to the team but fail to mention how it will also help the organization's customers.
Whatever the reason is, the common thread in these failed attempts is the lack of expressed value towards testing. If your manager or company doesn't understand how testing can help your teammates and the organization as a whole reach their goals, you're facing an uphill battle. Trying to convince them at this point about adding something like test automation into the mix becomes a nearly impossible task.
As a proponent of quality in your workplace, it's your responsibility to point out the importance of this kind of testing in the context of your projects, your team, and the organization. You can't expect everyone to assume that automation will benefit them, so help others grasp its importance to help them reach their goals.
Making the importance of test automation clear can get you moving forward, but that's only part of the battle. You'll also need to illustrate that value in a tangible way for a better chance at succeeding with your efforts.
Talk is cheap - it's all about demonstrating value
You might have the ability to successfully talk your way into introducing test automation for your project. However, it's not as easy as it sounds, mainly if your team or organization isn't used to having different kinds of testing for their projects. For a higher chance at obtaining a successful outcome, it's ideal to show them that value first-hand.
At this point in the process, most testers will likely give up on their efforts if they haven't received the green light to proceed. They think that if management hasn't expressed immediate interest in automation, there's nothing they can do about it. In some workplaces, you really might not have a choice. But in most modern software development shops, there's a good possibility you have some options if you're willing to show some initiative. Here are a couple of tips that I've found effective when it's time to demonstrate the value of test automation when your company or manager is on the fence.
Come up with a plan, and make it doable
The first thing you should do is figure out what tests you can automate to demonstrate value without a massive overhaul of existing processes. Since this is something you'll likely work on by yourself or with minimal resources, an excellent suggestion is to organize some tasks that will get you moving and have something to show for it quickly. Also, plan around leveraging your current knowledge. At this point, it's not the right time to experiment with new testing tools or frameworks.
You don't need to take tons of time coming up with a formalized plan for this purpose. The only thing you need is to decide what steps you need to start with to have a working automated test suite with a handful of high-value scenarios. For instance, your plan may consist of setting up a test automation framework or library suitable for your project and writing test scenarios for a few areas of your application that would benefit significantly from test coverage.
Take extra time beyond your existing tasks
With your initial tasks at hand, the next step is to begin putting your plan into action. If you're working on setting up test automation on your own, it likely means you'll have to do these tasks alongside your existing workload. It can be a daunting road ahead, and it's a sacrifice you'll have to make if you truly want to have test automation as part of your processes.
Doing this work on the side doesn't mean you should keep things a secret or sneak behind your manager's back. You can integrate your work towards test automation as part of your existing routine. For instance, if you're documenting new features to test, you can write automated tests to cover those scenarios. By showing your team that you're going the extra mile with implementing test automation while doing your work with no delays or interruptions, they'll take note and begin pitching in.
Track any metrics that come from the work you do
An automated test suite will aid developers and testers, but you also have to demonstrate value beyond the team working directly on the application. You have other stakeholders - both technical and non-technical - that will benefit from seeing the benefits of test automation. They might not understand the technical portion. However, they will definitely understand when seeing evidence that your efforts lead to things like faster development times and fewer customer support requests due to bugs in the system.
As part of your initial plan, you should also consider which metrics to measure throughout your initial implementation, setting up a baseline to compare against. You can use your existing bug tracking software to measure if regressions are trending up or down. If you're on an Agile workflow, you can track the team's velocity to see how quickly they're getting new functionality to customers. Valuable metrics are difficult to find for any testing project, but you'll still need to track something to prove that automation is worth pursuing (or not, in some instances).
Case study on demonstrating the value of test automation
This topic feels very close to me because I found myself in this exact situation six months ago. I joined a small startup as a software engineer, working on building the backend for a web application. The existing development team (one backend engineer, three frontend engineers) was working furiously to complete the app's first release when I got on board. Because of self-imposed deadlines, they skimped on automated testing entirely, so there were a total of zero tests.
The organization didn't have any team members specializing in QA, so they only relied on manual testing from a handful of people who aren't technical. As you might expect, the beta version of the app was extremely buggy and riddled with all sorts of issues. Fixing those bugs was a time-consuming process, slowed down by the manual testing whenever the small team had time to go through the changes. In a tiny startup, you barely have time for all the work that needs to happen, so thorough testing was never high on the company's list of priorities.
Every push to our staging servers seemed to uncover a slew of new bugs, repeating the sluggish cycle from the start. Having seen this scenario many times in my career, I knew the company wouldn't be able to sustain this pace in the long term if they wanted to grow their business. I brought the topic up to the current team, and while they agreed that test automation would greatly benefit us, no one thought it could happen any time soon since there was so much work to do. I couldn't accept this response, so I volunteered to get the ball rolling while our push to Version 1.0 moved along.
First, I spent an hour or two after work setting up the tooling for test automation. Since the tech stack for the application is one I'm intimately familiar with, I knew which tools would help me start immediately. Next, I examined our exception handling service and bug reports and spotted a few common areas where the application broke down often. I took these sections and sorted them out by which would be the quickest to cover with some automated tests.
With the tools in place and my list of high-value targets, I started to implement new automated tests as part of my assigned tasks. Every time I touched a segment of the codebase to fix a bug, I would always try to add some automated tests to cover regressions. I also enlisted the help of one of the frontend engineers to set up some basic end-to-end smoke tests and get that process rolling. The primary purpose for this was to alleviate some of the repetitive work done during the usual manual testing cycle.
I continued plugging away at writing tests and keeping track of our deployments, velocity, and the number of errors appearing in production. After about six weeks, I could see that all of those metrics were improving significantly. We were deploying quicker than ever due to fewer bugs popping up during development. The organization saved days on testing, thanks to having less of a need to do the same manual checks repeatedly. Bugs rarely popped up in production, and if one did, the team squashed them at a faster rate than ever.
Fast-forward to today, where we've built a suite of over 800 automated test cases spread across unit, API, and end-to-end tests. We went from spending days waiting for manual testing cycles to less than one day. We've been able to grow the application much faster than planned on the roadmap. If I had waited for explicit permission to begin implementing test automation on this project, I'm sure I would have never been able to start, and the application would still have zero test automation in place.
Summary
Lots of testers find themselves in a work scenario with little to no test automation. However, when they bring up their desire to start, they don't have much success. Usually, the issue is because they haven't expressed the value that automation can provide to software projects. They fail to talk about how it fits into the existing workflow and how it can help the team and the organization's customers.
Failing to express the value that automation can provide leaves management thinking that testing is more work than it's worth. It's up to you to make a case for test automation and how it can help your company reach its goals effectively. Part of that is articulating the value of this kind of testing, but it's even better to show it. Demonstrating direct value will take you farther than just presenting arguments in favor of automation.
You don't always have to wait for explicit permission from your manager or organization. You can produce a manageable plan, implement it while handling your day-to-day work, and track metrics to show the positive benefits. As long as you don't let your existing work slip, have an efficient plan that doesn't disrupt anyone, and track crucial data points for your organization, you should have the capacity to show everyone how test automation helps.
How have you managed to express the value of test automation to your team or organization? Help your fellow testers by leaving your tips and advice in the comments section!
