14 Test Automation Mistakes I Wish I’d Known as a Newbie Tester

When you start your journey as an automation tester, then mistakes are bound to happen. They may also happen if you are up in a race to automated website testing without exploring the impact of your Selenium test automation scripts in depth. And while it is good to learn from your mistakes, it is always better to be preventive by learning from others.

When handling an automation testing project, you have got a huge responsibility. Your improper sign off can lead to a production outage which could eventually lead to customer & reputation loss. I have been at the receiving end a couple of times and it has not been a pleasant experience. So I now make sure to avoid these 14 test automation mistakes which I am about to share with you. Make sure to make a note of them so you don’t end up with a red-faced moment.

If you’re new to Selenium and wondering what it is then we recommend checking out our guide – What is Selenium?

Automate When It Is Necessary

When I was handed the responsibility to automate Selenium test scripts for my web-application, I was as joyed as I was nervous as it was my first assignment towards the team. The first impression is always crucial and I wanted mine to be perfect. I was handed to automate one module of the web application and I was comfortable doing so. However, I wanted to do automate a little more and so I picked up another module from my own understanding. I hit a dead-end and failed to automate that one. Now, attempting to automate a new module wasn’t wrong. Wrong was me trying to automate that module without consulting my seniors. Turned out that module wasn’t meant to be automated as the integrated system could result in multiple false negatives and false positives. I spent my days on that module which was never meant to be automated. I even ended up neglecting the rest of my responsibilities. So much for a good impression, right?

I have seen it happen many times with new automation testers. After all, curiosity can take you places. When you learn automation testing, you may try to bring in automation in every project. This is not necessary. You may be able to automate a certain thing, but is it feasible enough? While it is known that automation saves time and effort, it is absolutely important to answer the question: Why do you need to automate this project? If you get a pragmatic answer, only then show the green light to automation. It is vital to avoid this mistake as an automation tester.

Define The Scope

Defining the scope of the tests that you are going to execute is extremely necessary. When I was a new automation tester, I tried to test everything and make every test automated. The problem is that although you can successfully automate all the tests, it is neither practical nor viable. Firstly, there are many parts of a code that do not need frequent testing and we may need to invest a lot of time in developing a framework or script just for these codes.

For example, while testing a website using Selenium, it is useless to automate each element of the website and run your scripts over it. This is not worth the time and money. Secondly, automating everything increases your test automation percentage which makes you feel like you have done an exceptional job, which is not true. It might look good on paper but it is not required. Define the scope of the tests and consider only viable codes for automation testing that provides real value in time.

Select Your Automation Testing Tools Wisely

Another one of the most common mistakes as an automation tester is not picking the right automation testing tool. A project contains many components that focus on different testing objectives. These objectives should be divided into different tools that can help achieve that objective more efficiently. For example, if you want to test an API for your website, you better go with Postman but if you wish to ensure a flawless rendering of your web -application across different browsers then an online Selenium Grid is your best call for automated cross browser testing.

The straight-forward method for such a situation is that do not jump on software and then try to solve the problem through that software. First, find the problem and then find a suitable tool for it.

Coordinate Well With Fellow Testers

There are many people involved in a testing team. All these people are equipped with a different skill set. For example, someone is good with business testing while someone is good with functional testing. However, that is no reason for you to not discuss the progress of your tasks with them. Coordination is the key to accelerating product delivery. Acknowledge who is working on what, which tools are they using, which programming language for test automation are they comfortable with. Why?

That would definitely help you troubleshooting your test automation scripts. So in case, things go south, you will know where to knock or rather whom to knock!

Knowing your team would also help you manage them when demanded by the time. As discussed in the last point, a project might require different tools to achieve the combined objective, it is best that you let your testers use the tool with which he is comfortable.

It is very important not to force anyone randomly with any task and tool. For this, you can always perform a dry run before starting the testing process. If no one suits fit, you need to train them accordingly.

Check For Return On Investments

It is a very rookie mistake to just take into account the tester’s salary as the cost associated with the overall testing process. I did the same during the initial days. Obviously, this is not the case. For example, let’s consider that you want to perform cross browser testing of your website. A tester’s salary is obviously a part of the cost. If your team does not know this type of testing or any tools associated with it, then you need to upgrade their skills by training them about it. This incurs extra costs. In addition, you need to have the right automation tool or framework to perform automated browser testing.

Now, you may be thinking about opting for an open-source framework such as Selenium. That way, you might not have to pay more, right? Well, like all other things Selenium isn’t perfect. There are a few challenges to Selenium automation testing. The major one lies with the scalability. As you may know, a Selenium Grid will help you perform parallel testing which is great. However, you can only test your websites across the browsers that are installed in your machine which is offering Selenium Grid. Now, you may have to test across hundreds of browsers, browser versions over different operating systems for mobile and desktop devices. Doing so on your own will be time consuming and expensive. Opting for a device lab is going to hurt your pocket. So what can you do?

RUN AUTOMATION SCRIPTS ON SELENIUM GRID

2000+ Browsers AND OS

FREE SIGNUP

You can look for an online Selenium Grid such as LambdaTest. Our Selenium Grid helps you to test your website across 2000+ real browsers and real operating systems. The best part? It is all on the cloud, which means you can ditch the hassle of maintaining your in-house infrastructure and choose to go for distributed machines hosted on the cloud. You would not only end up saving time but also money.

This was just one instance. Similarly, there are other investments that you will encounter on your way to perform automation testing of a web application. But, they will definitely appear. So, the testing costs should be considered carefully keeping in mind the return on these investments that you will get. If the return is less, you need to change the strategy and again calculate it. But in the end, you need to have a good ROI on your overall testing process.

Not Every Open-source Is Going To Be Gold

Open source tools are becoming popular every day. They are really great in terms of users, support and community. The best thing about open-source software is that there are a huge number of developers involved all around the globe which leads to its faster improvements. But, that does not mean that you pick up or search for an open-source tool only. The developers of open-source tools also need money like everyone else. So, more often you might not find open-source software loaded with features and even if few open-source are providing tonnes of features, there is no telling for how long! Software bugs might pop up and an open-source tool with low community support is going to have a hard time finding fixes to these bugs. And you might finally realize that this was your big mistake as an automation tester.

So it is always recommended to use open-source frameworks with large community support such as Selenium for web application automation testing. So, before starting out, do not settle your mind on the open-source category only. If open-source suffice your requirements, it’s great, but if not, then you need to have appropriate software with you.

Consider Codeless Automation As A Stepping Stone

While codeless automation testing tools have a narrow learning curve and are easy to get started with, they won’t help you build a relevant skill set required for your automation tester profile. As a beginner, they are good to get you started but as you grow your test automation career, you would realize that they aren’t as helpful as you expected them to be. And if you decide to sit in an interview for an automation tester profile with the wisdome of codeless automation tools, or if you thought you could automate your complex web application with codeless automation alone then you are going to have a rough time cracking it.

Reliability is another big question in these types of tools. At the end of the day, you need to learn code in order to debug where your automation test suite execution is going wrong. Also, if you are handed a complex website to work with, then you would not find codeless automation testing tools to be as flexible as you like. It is advised not to run away from code but to learn it proficiently. On top of that, it would be a charm to your resume. So make sure to avoid this common mistake as an automation tester.

Maintain Test Design

Test design is a process of converting the general test objectives into tangible test cases and conditions. As a developer, we tend to think that since testing requires coding, why can’t developers do the job? Well, if that would have been the case, then tester’s would not have existed.

As a beginner, I did not understand the importance of test design and that was probably my biggest mistake as an automation tester. Testing anything anytime is an absurd idea. To test efficiently, testers are required to design the tests and then code them. Designing the tests helps create meaningful tests and makes the overall testing process very efficient.

Avoid False-Positive and False-Negative Results

A false-positive occurs when the test results wrongly indicate that the test passed but in actual, the test did not. A false-negative is vice-versa. Believing blindly on the test reports is a very common mistake among the testers. This can also be called as non-validation of the elements you are testing. For example, let’s say you are testing a login page with test scripts written with different test cases. The test reports indicate that the login passed. In such a case, you need to validate whether the login was successful or not. Don’t fall for this mistake as an automation tester by always being on toes for false negatives and false positives.

Focus On Code Reusability

A test case is not unique to the code it has been applied to. In a project, many similar components occur and they require similar test design and test suites. For example, while cross browser testing with Selenium, we found out that four elements of a web page are all input fields and require similar test cases. Here you can copy-paste the code by writing the tests for the first element only. While this will give the expected results, the problem is that in the future the developers might change the elements in some way. Now, to change the test cases you need to change the code in every test suite that you wrote. The entire time will be wasted on finding and modifying these test codes. I did this mistake and I can tell, this turns very ugly while testing.
To avoid this, you should always focus on the reusability of the code. Instead of pasting the code, again and again, you should construct a function with appropriate arguments and call this function on each element. This way, if there is any future change, you just need to modify the function and you are good to go.

100% Automation Is A Myth

Don’t fall for this myth as it would be a grave mistake as an automation tester. As a newbie in the test automation area, I was excited to bring automation to the projects. This led me to commit the mistake of thinking that automation testing can replace the manual testing process completely. In the course of time, I have known that this is not possible. Replacing manual testing with automation testing completely (100%) is a myth. It can never be achieved. As a beginner in this area, do not try to achieve such a goal. Automate only when it is necessary and only those things that require automation.

Follow Ground-Up Approach

While testing you will encounter different types of problems. You will be required to set objectives and categorize these problems. A ground-up approach means start automation testing with smaller modules rather than the big ones.

One of the biggest mistakes as an automation tester is to start automation with bigger and complex modules. Don’t do that! You lack the awareness around the inbound and outbound processes involved in each user interaction. You may even lack the proficiency to handle tricky test cases and you may end up wasting a lot of time with nothing to show for it. So start small and increase your automation testing coverage from a ground-up approach.

Involve Exploratory Testing

Not incorporating exploratory testing in your weekly routine is one of the common mistakes as an automation tester. Exploratory testing is a great adventure that helps in finding new test cases. Exploratory testing is very crucial when we are into automation. Being just on the test scripts might ignore some unexpected and important test cases in automation testing. As a beginner, we just want to rely on scripts and pre-written tests, which should be avoided.

Take some time out to perform exploratory testing. You may never know what bug you might catch while testing in the wild..!!

Design Test Impervious To UI

The user interface of the software changes a lot in the earlier builds. Automation testing helps us in repetitive execution of the tests and if that is not being achieved, then there is no point. In the earlier stages, a tester ignores these types of mistakes as an automation tester, I did too. Now, I know I shouldn’t have.!

The change in user interface forces us to change the test scripts. Sometimes an element changes its location in the future builds and the scripts took advantage of that location to test further. This complete test execution fails due to the location change which was something on which the tests relied. For example, while automated browser testing, if the location of a certain image changes, the Selenium automation testing script would not be able to find the location. This will fail the entire test. These kinds of tests, that rely on user interface should be written as less as possible.

Wrap Up

Automation is a booming industry. From small JUnit tests to larger Selenium scripts, everyone is moving towards automation. You might encounter the same code with small added patches and have to run the same tests again. With automation, the margin of error in repetitive tasks has been reduced to zero. But this stage is achieved only after some practice and experience into automation. While people are stepping into automation for the first time, they are bound to commit some mistakes. Although committing mistakes is no crime, but if you are working in a company or in a team, these mistakes cost you money, time and other crucial resources. Which is why it is better to be safe beforehand. I hope you will not succumb to these 14 mistakes as an automation tester. Happy testing! 🙂

Harshit Paul

Harshit works as a product growth specialist at LambdaTest. He is also an experienced IT professional, who loves to share his thoughts about the latest tech trends as an enthusiast tech blogger.

See author's profile