Making The Transition from Manual to Automated Tester

Introduction

Test automation has been around for many years and is gaining more traction as tools become more user-friendly and testers have become increasingly more technical. More and more employers are adding technical skills as requirements for many QA and testing roles, including QA analysts.

But what about manual testers who are proficient in finding failures by traditional, manual tests? How does a manual tester gain the skills to apply test automation? And, should manual testers feel they must make a shift to more technical approaches to testing?

In this article, we will explore some options for making the transition from manual to automated tester as well as guidance to whether or not test automation is the right move for you.

Is Learning Test Automation a Good Career Move?

I recently conducted a very random survey of job postings for “QA Analyst” at a leading job search website. I found that over 90% of the job descriptions for “QA Analyst” either required test automation experience or indicated test automation experience would be desirable. Even more interesting was that in the search results for “QA Analyst”, about half of the job titles were for “QA Automation Analyst” or “QA Automation Engineer.” That is very significant.

I found no postings that indicated purely manual testing in the job descriptions.

While this sampling is just that – a sample, it does give a strong indicator that test automation is something you should be thinking about in your QA/testing career.

In my own case, test automation has been a very big part of my success in the QA and testing field. I was fortunate to get into test automation at the very start in the late 1980’s. Today, I work with test automation about 90% of the time.

Manual vs. Automated Testing

Manual and automated testing are two fundamentally different approaches to testing, each requiring a different set of skills and attributes. There is shared territory between these two approaches, and one is not necessarily better than the other in certain cases.

Despite what some may assert, test automation is testing. It looks and feels different from manual testing, and the goals are often different, but it is a form of testing that can give you great leverage in your overall testing efforts.

If you don’t understand what makes a good test, your automated tests will be weak. I see these weak tests often when I conduct testing assessments in organizations.

One helpful analogy is what I call “the power tool analogy”.

Imagine you want to build a bookcase. Instead of cutting the wood with a handsaw, you go to the store and buy a power saw. Back home, you start cutting the wood to make the shelves. But wait a minute…

If you don’t know how long the boards should be, or how to make a straight cut, you will have some really ugly and non-functional shelves. The lesson is that before the tool is helpful, you need to understand the fundamentals of not only using the tool, but of woodworking itself.

The same applies to testing tools. To intelligently use testing tools, you need to first understand how to test the thing you are testing.

What is Test Automation, Really?

As a tester looking to move from manual testing into test automation, consider that you are essentially creating (or using) software to test software. If you are using a code-first approach, then you are in the role of software developer as much as a tester.

You will learn in test automation, the same skills are needed as in coding. Namely, problem-solving, attention to detail, thinking in repeatable patterns, creating maintainable scripts and so forth.

No Code/Low Code Tools vs. Scripted Tools

There is an important distinction to be made between the tools that require little or no initial scripting (no code/low code tools) and those that are entirely “code first”.

The no code/low code tools (for example, Selenium IDE) allow you to record a test session and replay it exactly as initially recorded. This looks good in a demo and in some cases, it might suffice for your test automation needs.

Those who have worked in test automation for a while know that, at some point, some kind of manual coding effort will likely be needed to handle special conditions, such as unexpected error messages, looping conditions, and so forth.

However, there is value to using no code/low code tools to create an initial test script, then modify it as needed. This can save a lot of time as compared to starting from a blank screen and writing a test script, or copying an existing test script and adapting it.

One other great advantage to no code/low code tools is that they are often easier to learn than pure scripting tools and languages. This means that the adoption of the tools by testers will be higher and your test automation goals might be reached far sooner than with code-first tools.

The “code-first” tools (such as those based in Selenium WebDriver) are more labor intensive and require more technical expertise than no code/low code tools, but can handle more complex situations.

At first, learning code-first tools can be challenging. But, with some dedicated effort, you can start with basic commands and work up. Remember, however, that code-first tools can be more labor-intensive, especially when it comes to maintaining your test scripts.

Helpful Test Automation Principles

Now, for some test automation principles that will serve you well in making the transition from manual tester to automated tester.

Principle #1 – Test automation is about more than just the tools

When people think about test automation, the first thing that comes to mind is tools. “Which tools do you use?”, “How long have you used the tool?”, and so forth, are questions often asked.

Questions you seldom hear asked are:

• “What is your process for using tools?”
• “How do you design and implement your automated tests?”
• “Where do you manage and maintain your automated tests?”
• “Who trains and mentors your team in test automation?”
• “How wide is the adoption of test tools in your organization?”

I would suggest that those questions are probably more important than which particular tool you are using, or plan to use.

I often describe testing as an “iron triangle” of people, processes, and tools – all in a controlled test environment (Figure 1).

Figure 1 – The Iron Triangle of Testing

Of course, the Iron Triangle or “PPT” as some call it, is not just for testing. You can see it in many things – software development, IT security, and so on.

The thing to take away from this figure is that these elements must be in balance for efficient testing. If you have tools, but no process for using them and the people lack the motivation to use them, then you will have unused tools – also known as “shelfware”.

Likewise, if you have tools and motivated people, but no process, then you are at risk of creating a lot of random, unorganized automated tests.

Finally, if you have process and people, but no tools, then testing is laborious and often inefficient.

Principle #2 - Test tools do not tell you what to test

Since the inception of test tools, there has been a missing piece in tool training. That missing piece is that in tool training you learn how to automate a test with a particular tool, but in many cases, you don’t learn how to design a good test for the item under test.

In defense of tool trainers and developers, the focus of tool training should be on how to use the tool. However, failure to show how to create good tests with the tool will lead to ineffective tool results.

Once training is over and you try to use the tool in your environments and with your applications, you really start to learn what you don’t know.

Too many people believe that just acquiring a test automation tool will give them more test coverage and better tests are mistaken. Test automation tools test what you tell them to test and how you tell them to test.

That means that even in test automation, there is still the job of analysis that must be done by someone.

Principle #3 - Test automation often requires problem-solving

Working with test automation on a daily basis, I spend significant time-solving problems.

In some cases, there may be an unexpected script failure. So, I must determine if my test script is incorrect due to some change in the application, or perhaps there is some environmental issue that needs to be addressed. Or, there could truly be a defect in the item under test.

Problem-solving in test automation can also go beyond just the tests themselves. Perhaps you need to devise a way to test something new that may not be easily done with your current tool and approaches.

Problem-solving is as much a mindset as it is a skill. Once you learn how to think about problems, gather information, and test your hypothesis, then you are on the road to being a problem solver.

One book I highly recommend for making this transition to becoming a problem solver is Are Your Lights On? By Gerald Weinberg. It is not a new book, but a good one on the topic of problem-solving in a technical context.

Principle #4 - Automating a basic test is one thing. Automating a robust and rigorous test is something else

As mentioned earlier, in tool demos and training, most of the examples are pretty basic tests. You might think of these as smoke tests or sanity tests. In fact, much of regression testing is fairly basic and confirmatory. However, there are times when you may need to automate negative tests.

As an example, the application I create test automation for is to allow people to place food orders. The requirement is that the maximum order amount is $75. So, I created an automated test to verify that orders over $75 were not allowed. However, soon after that test was implemented, a defect was discovered that people could not place orders over $20!

My original test was correct by all the testing theories. Less than or equal to $75 was the “valid” class, $75 was the boundary value, and over $75 was invalid. But…there was a defect in the “valid” range or class that occurred!

So, to help identify those situations in the future, I created a test script that would test at various price levels, such as $20, $40, $60, $75 and over $75. While not perfect, it was a better test than before.

Principle #5 - You can have bugs in your automated test scripts

In test automation, you are creating code, either manually or with a generation tool. Essentially, test automation is “software testing software” This presents the opportunity to have defects in the code to test the code.

The tricky part is that some defects in test automation are very obvious and others are not obvious at all. Sometimes the test execution will fail at the point of a scripting defect and sometimes the script will execute just fine but do something other than intended. In fact, the test may “pass”, but for the wrong reason.

This is why it is often necessary to watch your scripts run visually from time to time.

Principle #6 - Maintenance of the automated tests will likely consume a large part of your time

Reduction or elimination of test automation maintenance has been the holy grail of test automation for many years. Yet, test script maintenance is still one of the greatest challenges of test automation, even with tools using AI and “self-healing” scripts.

“Self-healing” scripts can help with changed locators, but not much when the process involved in the test changes.

Take a look at the rate of change for your applications and consider that those changes will come directly downstream to you in the form of test maintenance and test automation maintenance.

This is why more automated test scripts are not necessarily a good thing. You can easily reach a point where you spend as much time maintaining test scripts as creating new ones.

Test script maintenance might be easily dismissed by some as just changing one small part of a test script. However, when considering going into test automation as a career, you must understand that test script maintenance can get very challenging at times.

To be clear, there are ways to create test automation that fosters easier maintenance. Examples are data-driven tests, modular tests, and keyword-driven tests. (Figure 2)

Consider the tests shown in Figure 2 as we might be automating the functions of adding a customer, making a change to their information, then at some point in the future, deleting the customer’s information. This is basically the normal lifecycle of a customer.

Figure 2 – Modular and Reusable Tests

We could easily automate the test of these functions in one linear test script. But, what if we decomposed the test into three smaller scripts – one for each function? Now, we have a modular structure, much like building blocks. A driver script will control how and when each modular script gets executed.

If we want to perform a second test to add a customer, then add that customer again, we need no new scripts. We just create a new driver script or extend the one we have for Test #1 to perform the Add Customer test twice.

And… we could carry this thought to other tests, like Test #3, which is totally different than Test #1 and Test #2, but requires no new test scripts.

Now, consider this is just three small test scripts. Think of what you could do with ten such scripts! It makes test design and implementation much faster and easier.

However, the greatest payoff is when a change is needed the change can be isolated to one or a few scripts as opposed to every script! For example, if Script 1 needs to change, I just have to change that one script. I don’t have to track down every test where “Add Customer” is involved.

As you consider making the transition to test automation, this is just one example of how you will need to start thinking about your tests. Of course, this is an organizational decision on exactly how test automation architecture should be implemented, but the thought remains that to be really effective in test automation, there must be efficiency in test organization.

Principle #7 - Test automation does not replace people. Rather, it shifts them into different roles

We live in an age where there is justifiable fear of people being replaced by automation. In fact, that has been happening for some time, it is just now becoming more apparent.

I can understand why senior management would think that a test automation tool could replace a good percentage of their testers. However, that view leaves out at least two key things.

• Test automation can increase productivity over time, which in turn allows testers to focus on tests that cannot be automated. So, testers are still needed to test things the tools can’t test.
• As mentioned earlier, even with good test automation, key activities still need to be performed by humans. Test planning and analysis is still needed. Problem-solving is still needed. Test design is still needed, and oh yes, someone to keep the automation running is still needed.

Principle #8 - Test automation is largely confirmatory in nature

Test automation can discover defects, but those defects are mainly due to regressed functionality. Regressed functions are those that no longer work correctly. Regression testing is how we find those defects.

This is an important point to understand because if test automation is being judged by the number of defects found, it could be considered a failure.

Test automation is actually more like a safety net to find those defects in functions that normally work fine, but for some reason have started to fail.

Don’t be surprised or disappointed if your test automation has a lot of “passes” as opposed to failures. This is normal. Of course, you must always be asking if the tests are too basic or easy.

Before taking the journey from manual tester to automated tester, it is helpful to know if you have the readiness to start the journey.

Regardless of any particular tool in use, employers often look for people with skills with specific languages, and we can’t always assume a “no-code/low-code” tool will be used. If you possess code-based skills, it will be very easy to apply the no code/low code tools. It is in this context that this self-assessment is presented.

If you answered most of these questions in a positive way, then you would probably do well in working with test automation. Even without current coding knowledge, if you have the right attributes and thinking skills, you can learn how to code.

A Brief Test Automation Skills Checklist

Here is a quick inventory of skills that you need to be successful in test automation. The good news is that skills can be learned and perfected over time with the right training and practice.

✓ Problem-solving skills – Can you decompose a problem and see the root cause? Can you identify the best solution from a field of options?

✓ Logical thinking skills – Can you follow a series of events to determine a logical outcome?

✓ Analytical skills – Can you study a situation to understand it well?

✓ Technical skills – Can you work with databases, build test environments, work with shell scripts, and so forth?

A Test Automation Attribute Checklist

Attributes are more about your personality and who you are. You can work on these to some extent, but you don’t get better overnight. It’s like the old joke about patience, “I need patience right now!” Here are a few attributes that are often needed in working with test automation:

✓ Persistence – Can you stay at something until it is done, even if it is difficult?

✓ An eye for detail – Do you notice small things?

✓ Patience – Do you have the ability to not get frustrated easily?

✓ Creativity – Can you devise creative solutions to difficult problems?

How to Build the Skills Needed for Test Automation

My number one piece of advice for building test automation skills is to start automating something, in someway. Selenium IDE is a free and easy way to start learning test automation. Selenium IDE is a browser plug-in that works in Chrome and Firefox.

Next, find a good book or online course on general test automation. The reason I suggest general approaches is that they can be adapted to specific tools and languages.

Books I have found helpful are: Experiences of Test Automation by Dorothy Graham and Mark Fewster; Test Automation in the Real World: Practical Lessons for Test Automation by Greg Paskal (This book is especially helpful for people getting into test automation).

Then, find a specific course or book on a test tool or language that is in demand. Some examples include Selenium WebDriver and the Python language. You can also perform your own job search research, or find out in your company which tools are being used and start there.

Once you understand the territory of test automation and have worked on course or book exercises, then you are ready to start your first actual test automation project. This may be entirely on your own initiative, just for your own experience.

For example, you might pick an open-source project to test. Mobile apps are more difficult to test because you will need a version of the app that can be installed in a test environment and interact with your tool of choice. Depending on the app, the developers may offer a beta test version that will interact with a mobile emulator using a tool such as Appium.

Because of the extra effort involved in finding and automating the testing of a mobile app, you probably want to stick with a web-based example at first.

Your goal is to be able to show specific practical experience in test automation of a real-life application.

Test automation skills are in high demand for software QA and test professionals. As a tester, you should have your own set of tools and languages that you can use to test web applications, mobile apps and APIs.

Remember that learning test automation involves much more than learning tools and languages. You must also develop problem-solving skills and build attributes such as tenacity, patience, and detailed orientation to be successful in test automation.

The journey from manual tester to the automated tester is not easy, but it is becoming a matter of career survival and is well worth the effort.