5 Common Beginner Mistakes in Test Automation

Hello everyone!

I was inspired to write this article by my students and also I wanted to arrange my thoughts about hiring new test automators since I'm a QA Automation Lead on the current project.

Plan

So let's define these things that expose juniors and then talk about them in more detail:

1. SSH keys usage
2. Hardcoding sensitive data
3. Using full URLs
4. Waits that are not connected to events
5. Chrome DevTools usage

It's not a full list, of course, but these are 5 common criteria that we are going to talk about.

SSH keys usage

Git is the most popular version control system and if someone writes code in the development team - they are definitely using Git to manage their code.

Platforms like GitHub, GitLab, and BitBucket have a method to checkout code using HTTPS: web URL and username + password authentication. This is the method that most beginners use.

Professionals use SSH keys to work with Git repositories and to connect to various remote servers via SSH protocol.

Hardcoding sensitive data

Another thing that juniors do is hardcoding some sensitive data like logins, passwords, and other credential data like authorization tokens. Of course, it gets the job done since your tests will do what they are meant to, but you might have critical vulnerabilities if you choose this method (and most companies don't allow that).

One of the right ways to store your sensitive data is to use environment variables that are not going to be logged anywhere in your tests run and of course which won't be reachable from anyone who are not meant to have access.

Environment variables may be set in your CI/CD pipelines options, all popular DevOps tools support this (Jenkins, CircleCI, GitLab CI, GitHub Actions and et cetera).

Using full URLs

See, since there are usually multiple environments that are going to be tested (let's say, production, staging, development...), then you're going to have a different base URL for each environment.

For example, your base URL (and probably your production one) will be:

example.com

1. example.com

   - for production

2. stage.example.com

   - for staging

3. dev.example.com

   - for development

It means that you should use paths only and set a configuration for each environment (base URL, browser, test runner options, hooks, etc.).

So URLs in your tests should look like this (example for JavaScript):

URL = `${baseUrl}/main`

It says that your URL will be set considering the chosen environment in your test run configuration. For example, if you chose staging, your URL will look like this:

stage.example.com/main

Waits that are not connected to events

This is my favorite one since a lot of UI Test Automators love to put some specific timeouts in their tests. They don't like to wait for some trigger event, it's much easier to put some timeout specified in seconds and try to perform your next actions then.

It's pretty obvious why this behavior is bad:

1. Sometimes waiting for some web elements to appear or become clickable takes too long, since most of the modern frontend is dynamic and some functionality is based on AJAX. It means that in cases where it takes long for a specific behavior to occur, then we need to wait that specific amount of time that might unusual for our test case (let's say that we were waiting 2 seconds for button to appear, but next time it appeared in 10 seconds).
   
2. Since most of the elements usually appear fast (in less than a second) and other behaviors occurs fast as well, we will have huge idle segments in our test cases which are going to be just waits. It means that our test runs will take an abnormally long time to run when they could run 2 or even 3 or more times faster using explicit and implicit waits.

These arguments that I've stated above also confirm that static waits make our tests fragile (flaky).

Professionals use smart waits in all cases where we must wait for something in tests. Smart waits are implicit and explicit ones, when we set a timeout for specific conditions to be completed, so we wait just enough for these events and do our next steps right away, without wasting any time.

Chrome DevTools usage

Google Chrome is the most popular web browser. More than 65% of internet users prefer it for their daily browsing and development.

Chrome, like other browsers, has developers tools, which help developers and testers in development to test and debug processes.

What any QA Engineer that works with web UI needs to know:

1. Reading logs from Console (logs, warnings, errors).
2. Running JavaScript code in DevTools console.
3. Using Network tab to see what requests your web application sends to your API server (websocket messages would be a huge plus).
4. Using Elements tab to navigate through DOM tree, modify it and create selectors (XPATH, CSS) for your UI tests.

So this final paragraph is actually not just for Test Automation Engineers, but it's also a must-have for manual QA Engineers.

Thanks for reading, I hope you've learned something new and now know what to improve if you're an Engineer that recently started a career in Test Automation.

I also hope that it's been helpful for those that are going to hire a skilled Test Automator and were looking for criteria that expose beginners.