What Software Testers Need to Know about Automation

Even if you're currently only using manual testing, it's still important to know about what's going on in the world of automation. Whatever your role is, your day-to-day job will probably be enhanced by using at least some of the approaches in this article. Here, learn what some common terms mean and some examples of how they might be used in a software development shop.

I recently tweeted about software testers needing to know about what's going on in the world of automation. It got a pretty warm reception, so I thought I should expand on my thoughts.

Whatever your role in testing is these days, your day-to-day job will probably be enhanced by using at least some of the following approaches. At a minimum I'd suggest knowing what these terms mean and an example of how they might be used in a software development shop.

Continuous Integration Services

One the biggest changes over the past decade when it comes to automation in software development has been task automation. In the past, things like building a particular version of an application, creating documentation, or updating the status of bug reports were done manually. Some teams even had dedicated individuals who were the "build person" responsible for initiating a build. Doing tasks like this manually (or with heavy ties to individual people or machines) was time-consuming and created annoying bottlenecks, such as the build person taking a personal day and blocking new builds from being completed.

Luckily, continuous integration (CI) tools came to the rescue by allowing tasks to be standardized and automated. CI services essentially schedule and execute tasks that a regular desktop computer can do and have these tasks execute on target machines other than itself. Going back to the build example, instead of having Bob being responsible for manually creating builds on his machine, a CI service can be set up to choose a target machine and execute a build on that machine. Not only does Bob not need to be physically present at the build machine, but builds can occur any time, either scheduled or in response to another action.

For example, Alice the tester may want a build of an application based on the latest changes to see if a bug has been fixed, and she can initiate that build herself. This not only frees up resources from doing repetitive tasks, but also gives more control to teams over individual and team workflows. You can also chain CI tasks together to further streamline some tasks. Learning how a CI service works is a great introduction to automation without a lot of emphasis on programming.

One way to make use of CI is to run end-to-end test suites. These tests often need to run for several minutes or even hours. I’ve used CI to spin up and spin down testing machines and to launch tests on those test machines. This is a big help compared to running these tests on your own machine, because it allowed for a test developer to do other tasks while tests run elsewhere. The CI server handled all aspects of these tasks.

Some popular examples of CI services are the open source tool Jenkins, the cloud-based Travis CI, and the proprietary tool Bamboo, but there are other ones as well. Even more low-tech is using a tool like cron or Windows Task Scheduler for use on a single machine to automate tasks.

CI is indispensable for developing software beyond hobby programs, and it’s one place where a tester can really add value.

Modern Source Control

I should first point out that I love source control. When writing code (or blogs!), it's too helpful a tool not to use. For a tester who codes, it's a no-brainer. Even if a tester doesn't code, using source control in a modern way can be a big benefit when testing software.

User Comments

Tom Sullivan's picture


A good summary indeed.  However, I'm disappointed that you didn't address the one question I was hoping you would: when is it appropriate to use automation and when not?  Should we automate everything even if exploratory testing would be more appropriate in some cases?  Should we just ignore the context?


November 29, 2016 - 3:34pm
Tomasz Lubera's picture

Hello, I guess you should not be disappointed one particular issue is missing from this summary, since in itself it has been discussed almost to death by other authors in their blogs/sites - however, I agree that the question you bring up really should be repeated sufficient enough number of times so maybe the word gets spread among certain decision making bodies who often push the A-word thing down poor testing teams' throats and it gets spread so effectively that maybe those bodies should finally acknowledge what I guess majority of testers/QA people approaching or about to tackle automation already know (being or claiming to be specialists in their field they should) about its optimum use - anyway, the piece focuses on other aspects of automation than the questions of when or whether or not to use it, and in my opinion, talking about it just was not the author's intent.

November 29, 2016 - 6:09pm
Tom Sullivan's picture

Yes, I agree that it wasn't the author's intent to talk about when we should automate and when we should not.  That's what I'm taking issue with, that such an important question would be left out of a summary of automated checking.

November 30, 2016 - 4:56pm
Tomasz Lubera's picture

TL; DR: the article is too developer mindset orientated and presented from a developer's point of view

I am revisiting this article to add a new comment since I got it sent in a top10 list for the passing year, out of curiosity if other people also commented on it, but primarily because one thing came to my mind since my initial readings of this piece, the "thing" being that the author of this article assumes and preaches from the position of a developer/programmer familiar with certain tools of the software development trade and while it is perfectly all right for anyone to be able to use said tools / technologies to facilitate and accelerate their work - be it development, testing, etc. - they are only tools that need a preferably skilled or fast learning user who in the first place has and can apply the testing knowledge and skills properly in the sense of being able to write / develop good tests and other testware (in other words, is a good tester) and knowing what to subject to automation at a later phase and why some such should be done, and only then, provided such tester is fairly proficient with technology and related skills (which v. often require ability to write code), knowing how to express those tests through code that forces the SUT to perform certain actions as if the "automation" code were a user with an OCD; the tools and technologies themselves will not produce or conjure any tests as they still haven't reached this stage of independence and intelligence - yet - and to counterbalance the point of view presented through this article, it might be supplemented with an account of a manual tester who crossed the Rubicon to the land of test automation and was successful, and who would share his experiences and advice with those manual testers (are there any in existence yet?) who want to or are forced (for fear of losing their jobs) to take up test automation (or better still, another article on the subject area might be commissioned by this site from someone just described).

December 21, 2016 - 4:42pm
Josh Grant's picture

Hi Tomaz,

Thanks for the replies to my article!

If I had to sum up my intention of thiis article, it would be something like "There are many modern tools and techniques that software testers should be aware of because they can be very helpful in some common contexts". When I was starting out in software development, one thing I learned early was that being aware of concepts like source control, bug tracking, details of software methodolgies like agile or waterfall, and so on. I didn't necessarily use these concepts on a daily basis, but merely knowing what they were helped look for jobs, work well on teams and decide how to approach some problems. Knowing what's out there usually helps open your options.

I know automation is hot topic in the software testing world right now (hence this article). Whether testers should get to know automation, programming or related tooling is a matter of context, but honestly it's becoming a common context. There's a whole bunch of ways to get into automation, and there's a whole bunch of great tooling/classes of tools to help folks in software development.

December 21, 2016 - 9:36pm

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.