Introduction

Test automation has gained popularity over the years as testing tools have become more accessible and testers have become more tech-savvy. As a result, many employers now require technical skills for QA and testing roles, even for manual testers who traditionally found defects through manual testing.

This raises questions for manual testers about how they can develop the skills to apply test automation and whether or not they should feel compelled to make this shift to a more technical approach. This article aims to provide guidance on these issues and explore options for transitioning from manual to automated testing.

Is Learning Test Automation a Good Career Move?

After conducting a survey of job postings for “QA Analyst” on a leading job search website, I discovered that over 90% of the job descriptions required test automation experience or indicated that it would be desirable. Furthermore, roughly half of the job titles in the search results were for “QA Automation Analyst” or “QA Automation Engineer.” Notably, I did not come across any postings that exclusively called for manual testing in the job descriptions.

While this survey is just a sample, it strongly suggests that test automation is a crucial aspect to consider in your QA/testing career. In my own experience, test automation has been a significant factor in my success in the QA and testing industry. I was fortunate to have entered the field of test automation in the late 1980s and today, I devote about 90% of my time to it.

Manual vs. Automated Testing

Manual and automated testing are distinct testing methodologies that require distinct skills and traits. However, there is a shared area between these two approaches, and neither is inherently superior in certain circumstances.

Despite some claims to the contrary, test automation is a type of testing. Although it appears and feels distinct from manual testing, it is a testing approach that can be highly beneficial to your overall testing efforts.

Manual vs. Automated Testing

Your automated tests will be inadequate if you don’t comprehend what constitutes a good test. This is something I often observe when conducting testing evaluations at firms.

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

Consider if you wanted to create a bookcase. Instead of cutting the wood with a handsaw, you go to the shop and buy a power saw. When you get home, you start cutting the wood to create shelves. But hold on…

If you don’t know how long the boards should be or how to create a straight cut, your shelves will be poorly constructed and non-functional. The lesson is that before the tool is useful, you must first understand not only how to use it but also the fundamentals of woodworking.

The same is true for testing tools. To effectively use testing tools, you must first understand how to test the item you are evaluating.

What is Test Automation, Really?

If you’re a tester planning to transition from manual testing to test automation, it’s important to recognize that you’re essentially developing or utilizing software to test other software. If you take a code-first approach, you’ll need to balance your role as a tester with that of a software developer.

In test automation, the same skills required for coding are also needed – such as problem-solving, attention to detail, thinking in repeatable patterns, and creating maintainable scripts, among others.

No Code/Low Code Tools vs. Scripted Tools

Distinguishing between no code/low code tools and code-first tools is crucial when considering test automation. No code/low code tools, like Selenium IDE, enable recording and replaying of test sessions without initial scripting, making it an ideal option for beginners.

However, manual coding may still be required for handling exceptional cases. Using no code/low code tools can save time by creating an initial test script, which can be modified as required, thus expediting the automation process.

No Code/Low Code Tools vs. Scripted Tools

Moreover, no code/low code tools are easier to learn than code-first tools, leading to higher adoption rates among testers. Code-first tools, such as those based on Selenium WebDriver, are more technically demanding but can tackle more complex situations.

Although learning code-first tools might be challenging at first, starting with basic commands and gradually progressing can yield significant benefits. Keep in mind that code-first tools require more technical expertise and are labor-intensive, especially when it comes to maintaining test scripts.

Helpful Test Automation Principles

Here are some test automation principles that can help you successfully make the shift from manual testing to test automation.

Helpful Test Automation Principles

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

Typically, when people think of test automation, the focus is on the tools used. Questions such as “What tools do you use?” and “How long have you been using them?” are commonly asked. However, other crucial questions related to the process of using these tools are often overlooked. Questions like “What is your process for using tools?”, “How do you design and implement automated tests?”, “Where do you manage and maintain your automated tests?”, “Who trains and mentors your team in test automation?”, and “How widely are test tools adopted in your organization?” are equally important and deserve consideration.

• “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?”

In my opinion, the questions mentioned earlier are more critical than the specific tool being used or planned to be used.

I often use the “iron triangle” model to explain testing, which consists of people, processes, and tools, all within a controlled test environment (Figure 1). This model is not exclusive to testing and is used in many areas such as software development, IT security, and others.

The crucial takeaway from this model is that these three elements must be in balance to achieve efficient testing. If you have tools but lack a process for using them and motivated people to use them, the tools will be unused or referred to as “shelfware.”

Similarly, having tools and motivated people, but no process can lead to creating random and disorganized automated tests.

Finally, if you have processes and people but lack tools, testing can become a laborious and inefficient task.

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

Since the advent of test automation tools, a crucial aspect of tool training has been missing. Typically, tool training teaches you how to automate a test using a particular tool, but it often fails to teach you how to design a good test for the item being tested.

To be fair to tool trainers and developers, the focus of tool training should be on how to use the tool. Nevertheless, not demonstrating how to create good tests with the tool can lead to suboptimal tool results.

When you attempt to use the tool in your environments and applications after completing training, you begin to realize what you don’t know.

Many people wrongly assume that simply acquiring a test automation tool will enhance their test coverage and produce better tests. However, test automation tools test only what you instruct them to test and how you instruct them to test it.

Therefore, even in test automation, someone still needs to perform the job of analysis.

Principle #3 – Test automation often requires problem-solving

As someone who works with test automation on a daily basis, I a significant amount of time is spent solving problems.

There may be instances where a test script fails unexpectedly, and determining the cause of the failure can involve identifying if the script is incorrect due to a change in the application, an environmental issue, or a genuine defect in the item being tested.

Problem-solving in test automation can also extend beyond addressing issues with the tests themselves. There may be situations where a new feature needs to be tested in a way that is not easily achievable with current tools and approaches.

Problem-solving requires both a certain mindset and skillset. Once an individual learns how to approach problems, gather information, and test hypotheses, they can become effective problem solvers.

A book that can aid in this transition to becoming a problem solver is Gerald Weinberg’s “Are Your Lights On?”. Although not new, it is a valuable resource 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 previously mentioned, tool demos and training usually showcase basic tests, often referred to as smoke tests or sanity tests. Regression testing is typically confirmatory and not very complex. However, there are instances when automating negative tests becomes necessary.

For instance, the application I work on allows users to place food orders, with a maximum order amount of $75. I created an automated test to ensure that orders exceeding $75 were not permitted. However, a defect was later discovered, preventing orders over $20.

Although my original test followed all testing principles, there was a defect in the “valid” range or class. To prevent such situations from happening again, I developed a test script that verifies various price levels, including $20, $40, $60, $75, and above $75. While not foolproof, it was a more thorough test than before.

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

When working with test automation, you are essentially creating code either manually or using a generation tool. In essence, test automation is a way of “testing software with software,” which means that there’s a chance that there may be defects in the code that needs to be tested.

However, identifying defects in test automation can be tricky, as some may be blatantly obvious, while others may not be so clear. There are instances where the test execution will fail at the point of a scripting defect, but in other cases, the script will run smoothly but may do something other than what was intended. In some cases, the test may even pass, but for the wrong reasons.

To avoid these issues, it’s important to visually monitor the script execution from time to time.

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

For many years, the ultimate goal of test automation has been to reduce or eliminate the maintenance required for test scripts. However, even with the use of AI and “self-healing” scripts, maintaining test scripts remains a major challenge in test automation.

While “self-healing” scripts can assist with changes to locators, they are not very effective when the process involved in the test changes. Therefore, it’s important to consider the rate of change for your applications, as these changes will impact test maintenance and test automation maintenance downstream.

Having more automated test scripts does not necessarily equate to a good thing, as you may end up spending as much time maintaining them as creating new ones. Some may view test script maintenance as simply changing one small part of a test script, but it can be much more challenging than that.

To create test automation that is easier to maintain, consider utilizing methods such as data-driven tests, modular tests, and keyword-driven tests. By decomposing tests into smaller, modular scripts, you can create a structure similar to building blocks. A driver script will control how and when each modular script gets executed.

For instance, you could automate the functions of adding a customer, making a change to their information, and deleting the customer’s information in one linear test script. However, if you break down the test into three smaller scripts—one for each function—you create a more modular structure. This enables you to create a second test to add a customer without creating new scripts, but instead by creating a new driver script or extending the existing one for Test #1 to perform the Add Customer test twice. Similarly, you could apply this approach to other tests such as Test #3, which requires no new test scripts but is entirely different from Test #1 and Test #2.

Having just three small test scripts highlights the potential benefits of this approach. With ten such scripts, you can significantly accelerate test design and implementation. The greatest advantage, however, is that when changes are needed, you can isolate the change to one or a few scripts, rather than having to update every script. For example, if Script 1 needs to change, you only need to change that one script, instead of tracking down every test where “Add Customer” is involved.

If you’re considering a career in test automation, it’s important to understand that test script maintenance can be challenging at times. But by adopting an efficient test organization approach, such as the modular structure described here, you can increase the effectiveness of test automation. Of course, the exact implementation of test automation architecture is an organizational decision.

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

In today’s era, there is a valid concern about people losing their jobs to automation. This has been happening for some time, but it’s only becoming more apparent now.

I can see why senior management might believe that test automation tools could replace a significant portion of their testing staff. However, this viewpoint overlooks two essential aspects.

Firstly, test automation can improve productivity over time, enabling testers to concentrate on tasks that cannot be automated. Hence, testers are still necessary to conduct tests that the tools cannot perform.

Secondly, despite good test automation, human intervention is still required for certain critical tasks. Test planning and analysis, problem-solving, test design, and maintenance of automation are all essential activities that cannot be replaced by machines.

Principle #8 – Test automation is largely confirmatory in nature

The use of test automation is primarily to detect defects resulting from regressed functionality, meaning previously working functions that have started to fail. This is why a high number of “passes” in test automation is normal, and it should not be judged by the number of defects found. Nonetheless, test automation serves as a safety net to identify faults in functions that typically functioned properly.

Before transitioning from a manual tester to an automated tester, it is essential to assess your readiness. Although employers may use no-code/low-code tools, having coding skills may be beneficial. Here are some questions to consider when evaluating your aptitude:

• Do you have any coding knowledge or experience, and how many coding languages are you familiar with?
• Do you enjoy solving problems and mental challenges, and do you have an eye for detail?
• Can you identify repeatable patterns and think procedurally and logically?

Having these attributes and thinking skills, even without current coding knowledge, can be beneficial in working with test automation. With the right mindset, one can learn how to code.

A Brief Test Automation Skills Checklist

With the right training and practice, you can learn and improve the skills necessary to succeed in test automation. Below are some essential skills to possess:

• Problem-solving skills: Can you break down a problem and identify its underlying cause? Can you select the best solution from various options?
• Logical thinking skills: Can you follow a sequence of events and deduce a logical conclusion?
• Analytical skills: Can you examine a situation in detail and comprehend it effectively?
• Technical skills: Can you work with databases, construct test environments, handle shell scripts, and perform other technical tasks?

A Test Automation Attribute Checklist

Personality traits are more innate and difficult to change, but it is possible to develop them over time with conscious effort. Developing traits that are useful for working with test automation requires a certain level of self-awareness and willingness to improve. Some important attributes for success in test automation include:

✓ Perseverance – Can you persist with a task even when it becomes challenging?

✓ Attention to detail – Do you notice the small things that others might miss?

✓ Patience – Can you remain calm and composed in the face of obstacles?

✓ Creativity – Are you able to think outside the box and find unique solutions to complex problems?

How to Build the Skills Needed for Test Automation

To develop your test automation skills, my top advice is to start automating something right away, even if it’s just a small task. Selenium IDE, a free and user-friendly browser plug-in for Chrome and Firefox, is a great way to start learning test automation.

Once you’ve got the hang of it, find a good general test automation book or online course that can be adapted to specific tools and languages. I recommend “Experiences of Test Automation” by Dorothy Graham and Mark Fewster and “Test Automation in the Real World: Practical Lessons for Test Automation” by Greg Paskal.

How to Build the Skills Needed for Test Automation

After that, focus on a specific test tool or language in high demand. For example, Selenium WebDriver and Python are popular choices. Research what tools your company is using, or do your own job search research to see which skills are in demand.

Once you’ve gained some experience with test automation and have worked on some exercises, start your first real test automation project. Consider picking an open-source web-based project to start with before moving on to mobile app testing, which can be more challenging.

Remember that developing test automation skills are about more than just learning tools and languages; it also requires problem-solving skills and developing attributes such as tenacity, patience, and attention to detail.

In conclusion, the journey from manual tester to automated tester may be challenging, but it’s essential for career survival in today’s job market. Build your own set of test automation tools and languages to test web applications, mobile apps, and APIs, and show your practical experience in test automation.