If you have ever spent a significant amount of time building an automated test suite, you know how much effort it takes to create something useful for your organization. What if, after all that effort, your tests lie dormant and unused by the rest of your team? It would feel like it was all a waste of time.
Unfortunately, it's not an uncommon situation. Many development teams say they want a robust automated test suite for their applications. Yet, when testers provide the test suite, all you hear are crickets. The development team never asks any questions. They never run the tests on their systems or give any suggestions for improving the test suite.
You can set up checkpoints to run the tests automatically after each commit, or when branching the code for release. The tests themselves may still provide value even if others don't bother to use them as consistently as you'd prefer. But if there's no buy-in from the development team, your tests will stagnate and fall by the wayside sooner or later.
As a tester, how can you avoid the fate of your automated tests landing at the proverbial graveyard of unused projects? How can you involve the development team more, have them run your tests consistently, and actively help shape the future of the test suite? Here is some advice you can use to move you forward.
Make your tests fast and easy to run
Test automation requires a balance of quality, coverage, and speed. More often than not, testers forego speed over the other segments of this equation. It's unsurprising since focusing on quality is one of the strengths of testers who want to maximize their efforts by providing as much coverage as possible. The problem is that no one wants to run slow tests.
Another issue that pops up occasionally during test automation is when people have to jump through hoops to run a test suite. This problem is evident if you need a checklist to ensure the tests run correctly. For instance, the test suite requires you to insert specific data into the database manually or to ensure that certain services are running before executing the tests.
If you have either of these issues in your tests, chances are no one on your team will bother running the tests because it's too painful. You're causing others to expend all of their mental energy on executing a test suite when they have other work on their plate. So your teammates will eventually decide to set their focus on their work instead of spending time running your tests.
You need to lower the barrier to entry if you want your team to use your test suite. When you're creating your automated tests, spend the time to make your tests run fast. Also, make your tests dead-simple to run. Instead of having a checklist of items to start the test suite, write a script to set up and run the tests, ideally with one or two commands at most.
Developers, in particular, focus on efficiency, whether it's on their coding work or when using the work of others. If you eliminate the roadblocks and make your tests efficient to start and to execute, others shouldn't have an issue kicking off a test run on their systems.
Demonstrate the usefulness of your tests
Have you ever heard someone tell you that they "don't understand what these tests do?" I have been a part of organizations where someone like a product manager has asked the development team if we thought the QA team provided any value to us. Even if someone on your team hasn't said this within earshot of the testing team, it's surprisingly a common question from other members of the group.
If you have experienced this, don't take it as a slight against you. Most times, it's an innocent question because others don't fully grasp the role of testers when it comes to automation. Automation testers write a lot of code, but it's not for functionality that the end-user sees, so they wonder what's the purpose of having someone spend time coding without any visible output. In a world where people value what's in their face more than what's behind the scenes, these scenarios will eventually happen to most testers.
In any organization, employees need to show what they bring to the table. Testers are no different. Whether you run your organization's QA team or not, you need to let developers know the real value of your work. You can demonstrate your test suite's usefulness in different ways, like finding times when the tests helped find a regression.
You also need to alleviate potential unease by explaining that the automated test suite isn't an extra burden that the development teams need to bear. Instead, let them know the test suite is a safety net to help both developers and testers deliver high-quality work faster. Make others understand that you're preventing more work down the road, not creating more work for them.
Even if you're positive that your test suite is delivering value to the rest of the team, you still need to "promote" your work. You can't expect everyone to immediately understand the benefits of testing, especially if they haven't seen how your work impacts them positively.
Dig underneath the surface for the real reasons
At this point, you have made your tests efficient and easy to execute, and you have clearly stated automation's usefulness. But if the development team's involvement with testing is still non-existent, there may be something else concealing the real reasons for the lack of support.
Often in these cases, there are issues lurking underneath the surface that might not be immediately apparent to you and your QA team. Sometimes you have clues that something's going on, and sometimes you're oblivious to what's going on elsewhere that's hurting your efforts. More often than not, the people causing these issues aren't even aware there's an issue to discuss.
If you suspect this is happening at your workplace, you need to figure out what's going on. Do a bit of investigation to coax the real reasons out of the developers or managers impeding your progress.
As an example, here's a quick story about a time I worked as a software engineer for a small startup. We had an outsourced QA team performing scripted manual testing, sending a report of their findings every morning. I began noticing that as our application grew in scope and complexity, more bugs slipped by their radar. I offered to help improve the QA team's testing by introducing more automation into our workflow.
However, I kept running into roadblocks for our engineering manager. Any time the subject popped up in our meetings, he would brush them aside and ask to bring it up in our next meeting. After weeks of the same response, I began prodding elsewhere, mentioning the issue to other department heads who were growing concerned about the uptick in regressions. I soon discovered that the engineering manager had been squashing the development team's attempts to spend more time on test automation during their meetings.
While he understood the value of automation and, he was more worried about his metrics. He worried we'd slip on delivered features if we spend more time testing, so he kept on putting it off. After learning this, I had a more in-depth conversation with the manager, and we came up with a plan that tempered his concerns, and the developers managed to assist the QA team with an automation framework. In the long run, we were delivering more features thanks to having to worry less about bugs.
The purpose of this story is to show that sometimes we don't have the complete picture as to why our automation efforts get ignored. If your best intentions keep running into obstructions, try looking elsewhere. It might surprise you to find the real reasons where you least expect it.
Summary
It's not unusual to have the automation work you've labored over remain unused by those it would benefit the most. Even when development teams ask for better automation, they fail to take full advantage of the test suite when presented upon them. If you don't tackle these issues early, your tests suite will die a quiet death sooner or later, languishing at the bottom of everyone's priorities. There are a few things you can do as a tester to avoid this fate.
First, take a good, hard look at your test suite and see how the tests work. Are your tests running slow and take forever to execute? Do others need to struggle to set up and run the test suite? If your test causes too much pain to run, no one will bother even looking at them. Make life easier for others by improving the speed and execution of your test suite.
Next, are you confident that developers and other departments in your organization know the value of a robust test suite? Surprisingly, it's a typical occurrence. Developers often don't grasp what testers bring to the table, especially since automation engineers spend lots of time writing code that isn't immediately visible to end-users. Justify your work to others. Demonstrate the usefulness of your tests and how they're a safeguard, not a responsibility the team must bear.
If you still find yourself struggling to get your work widely used and accepted as a tester, consider other places where issues might hide. There's a chance your manager thinks testing is a waste of money and development time. Maybe people got burned by a tester who worked at the company previously, and they don't trust automation. Whatever it is, dig deeper to seek the real issues and help with solutions to relieve any concealed fears others have.
Don't give up or feel demoralized if you think everyone overlooks your work. Whatever the reason is, you can show the importance of testing to others.
Have you felt like others have neglected your work as a tester? How did you overcome those obstacles? Share your story by leaving a comment!
Top comments (0)