Help! I'm a Manual Tester. How Do I Learn to Automate?

Keeping your skills up to date is an absolute necessity in any line of work, and the software industry is certainly no exception.

To illustrate this point, consider software testing. The challenges that you need to meet as a software tester are always growing greater. The volume of tests that is considered normal and the pace of testing are determined by current standards for application technology and performance, as well as the demands placed on applications based on current and likely future use. You simply cannot get by if you continue to apply yesterday's testing methods to tomorrow's technology.

This is why updating your skills is crucial if you are still stuck in the world of manual testing. Manual testing just doesn’t cut it in many cases anymore.

But fret not, manual testers. In this article, we walk through the basics of adding automated testing expertise to your set of skills.

What is automated testing, and why do you need it? Automated testing is in many ways a natural response to the recognition that most software testing is highly repetitive, and for human testers, time-consuming. Automated testing is algorithm-driven and reasonably easy to define in a way that is both abstract and formal, and its output consists largely of reports comparing clearly defined expected states with actual results.

In any industry, a set of skill-based tasks which fit this description would be a prime candidate for automation. The fact that software testing remained manual for so long was largely due to the somewhat complex conceptual nature of many of the tests involved, combined with the relatively slow and step-based nature of traditional Waterfall development. The move to automation has in many ways been driven by the demands of the DevOps model of software development and deployment, which emphasizes the use of script-driven automation tools for software production, and requires full integration of testing into the continuous delivery chain. In such an environment, manual testing has a very high potential for becoming a bottleneck, and thus must be automated in order to keep the continuous delivery process working smoothly.

Does this mean that software testers whose experience is largely manual are likely to be out of a job? Not necessarily—but it does change the nature of the (human) tasks that are part of the job, along with the skills which are necessary to perform those tasks. Even with these new requirements, however, the knowledge and experience which you have accumulated as a manual tester are likely to be of considerable value in making the transition to automated testing. Here are the key things that you (as an established manual tester) need to know about automated testing.

Automated tests run from scripts, and the scripts are, by definition, code.

Does this mean that you need to be able to write code in order to create, run, and manage automated tests?

Not necessarily. Many automated testing systems allow you to record testing scripts (by stepping through tests manually while the testing system stores your actions in script format), then play them back later. An automated test suite can consist of a set of recorded test scripts; you can typically manage such scripts through the testing system's graphic interface, or by means of a master script, or through the command line.

The trouble with using recorded test scripts is that unless you modify them, they will always run the exact test sequence that you recorded. In practice, of course, even the most basic test regime needs some flexibility in order to account for changes in the application, the platform, and operating conditions. While you may be able to make some modifications to a test script by means of the testing system’s graphic interface, in general, modifying a test script means editing the script's code.

This means that when you manage automated tests, you probably will need to learn to write at least some test-script code. In general, however, it's much easier to learn to write code by modifying an existing program than it is to learn by starting from scratch, so modifying test scripts is probably the best and most practical way for you to learn how to write code for automated testing.

Writing test scripts from scratch may turn out to be less of a challenge than it appears to be at first. Since test scripts serve a well-defined function within a specific domain, the scripts may (depending on the framework) be written in a limited-purpose testing language, which will typically have less overhead (and less of a learning curve) than a general-purpose language.

The framework may also accept scripting API calls from a variety of existing languages, allowing you to write tests scripts in a language with which you are already familiar. When you do this, the limited scope of the test domain means that you can probably focus on the subset of language-specific commands and features required for handling testing data, performing test-related operations, and making the required API calls.

Needless to say, automated testing doesn't happen in a vacuum. Typically, you will use an automated testing framework (either open source, such as Selenium or Appium, or proprietary), and very possibly a cloud-based testing platform (such as Sauce) to extend your testing capabilities, reduce testing infrastructure overhead, and coordinate test results and analytics.

The framework will typically take care of most of the infrastructure-related tasks required for automated testing (Selenium, for example, provides automated control of browsers). It will also typically provide the scripting API and related resources. A good framework should allow you to concentrate on the specific tasks required to test your website or application, rather than deal with basic infrastructure issues. Sauce Labs provides a variety of sample automated testing frameworks in a number of programming languages in this GitHub repo.

What if you aren't in a position to learn to write or modify test code, or if you are in a situation where you are unlikely to have test-coding responsibilities? Will automated testing put you out in the cold?

It doesn't have to. Even the most highly automated test system requires skilled, experienced people to design tests and test regimes, decide which tests to run, and interpret test results and analytics. These are all tasks that require in-depth understanding of the software being tested, the real-world conditions under which the software will run, and the actual meaning of test output.

If you are an experienced, non-coding tester, then don't throw in the towel. You may be able to find (or create) a position in test management, design, administration, and analysis.

Here are some links to basic resources that may be helpful for manual testers considering the move to automated testing:

Yes, there is a place for you (many places, in fact) in the world of automated testing.

Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues. He is a regular Fixate.io contributor.