This is a guest posting by Justin Rohrman.
When the topic of test automation comes up in a conversation between testers, most of the time the answer — even before any context is given — is “Selenium.” Selenium is a fine tool, but it is good for a small number of tasks, and there are many comparable tools to choose from.
Having testers working on automation from this focus further separates them from the development team. These testers (or programmers, really) are working with a lag because for the most part their tests can only be made from features that are already working, and they tend to work on a different team with different goals.
However, wanting to augment your career with a new skill set is a good thing, and I’d never want to stifle that. Exploring automation is valuable, so long as you do it right. Here are a few things, in my experience, that are useful to have testers work on in regard to automation.
Get TestRail FREE for 30 days!
Data Creation
Software runs on data, and the products I have been working on lately are all a data analytics platform in some way or another. Some of them have data input as part of the product; clinicians or patients might be filling out online forms. Other products I’ve worked on recently have been purely data display; we take large amounts of data from someone else who has been collecting it, and then wrap it up in software to help them use that data for good.
There are two difficulties here when it comes to testing. The first is that data is sacred for various explanations. Your customers are protective of their data, typically due to either business reasons (data is their intellectual property, and it getting out of their control represents a large problem) or regulatory reasons (HIPAA, SOX and so on). The second difficulty is the old chicken-or-the-egg problem: You need data to test your product so you can get customers, but you have no customers to give you test data.
Testers can add significant value to the development process by automating test data creation.
Let’s say you want to add a batch of patient data to your product. You are already familiar with iterative development, so you know starting small is the way to go. Start with first name, last name and email address. There are Ruby libraries to randomly select names and email addresses, so you search for those. Considering you’re reading this article, this is probably also one of your first forays into writing code. I want that to be a positive learning outcome for you, so I recommend that you pair with an experienced developer.
The key point is to start very small with something approachable and grow it from there. The product you want to test wasn’t built in an hour, and you won’t have a full set of test data in that amount of time, either. Set your expectations right and you’ll do just fine.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Continuous Integration
Continuous delivery, at its heart, is a process. The idea is simple: Developers should be merging with the main branch at least once a day to alleviate the testing and development problems that come with being out of date. Most non-developer people think of a tool when they hear “continuous integration.” CI tools can range in complexity from a glorified task runner to full environment management. In my experience, configuring this tool is usually done by either an ops person or a developer, who gets saddled with the job because they understand the tool, and everyone else ends up relying on that person.
Testers can add value here by learning as much as they can about their build system. Much like with the data creation example above, you will want to start small with a problem that needs to be solved.
The last company I worked with was having a problem with the amount of time it took for a build to complete. Every build took close to an hour, and a large suite of Cucumber tests were the main culprit, with the tests taking about 30 minutes to complete. That is a terrible feedback loop for a team that wants to be able to deliver to production a couple of times a day.
I spent a lot of time grumbling about the build time in retrospectives and to anyone who would listen. Eventually a developer agreed to pair with me on the problem. We found a Ruby gem that would facilitate running multiple Cucumber tests at a time with parallelization. We installed the gem on our CI system and build server and set the first experiment to run two threads. This effectively split the test suite in two and ran tests at the same time, so we were able to shrink the test runtime in half.
Other opportunities for understanding build systems can include container orchestration, server resource (memory and CPU) configuration, setting up workers and agents for specialty testing such as performance tests, and configuring new repositories to run tests through your tool. All of this falls into the realm of automation and technical work that a tester would be great at.
The Automation Question
When someone asks what testers should be automating, my general answer is “Very little.” Expecting someone who is not a programmer to take on a new software development project (yes, automation is software development) is foolish. However, there are several technical tasks that fall into the domain of automation, such as data creation and CI management, that a tester could be successful with, especially when working in a pair. These tasks are where testers can contribute the most value.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Test Automation – Anywhere, Anytime
