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 on the current project. QA Automation Lead Plan So let's define these things that expose juniors and then talk about them in more detail: SSH keys usage Hardcoding sensitive data Using full URLs Waits that are not connected to events 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 is the most popular version control system and if someone writes code in the development team - they are definitely using to manage their code. Git Git Platforms like , and have a method to checkout code using : web URL and username + password authentication. This is the method that most beginners use. GitHub GitLab, BitBucket HTTPS Professionals use keys to work with repositories and to connect to various remote servers via protocol. SSH Git SSH 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 pipelines options, all popular tools support this (Jenkins, CircleCI, GitLab CI, GitHub Actions and et cetera). CI/CD DevOps 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 for each environment. URL For example, your base (and probably your production one) will be: , so your environment-specific are going to be: URL example.com URLs - for production example.com - for staging stage.example.com - for development dev.example.com It means that you should use paths only and set a configuration for each environment (base URL, browser, test runner options, hooks, etc.). So in your tests should look like this (example for JavaScript): URLs URL = ` /main` ${baseUrl} It says that your will be set considering the chosen environment in your test run configuration. For example, if you chose staging, your will look like this: URL URL stage.example.com/main Waits that are not connected to events This is my favorite one since a lot of 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. UI Test Automators It's pretty obvious why this behavior is bad: 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 . 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). AJAX 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 (flaky). fragile 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 is the most popular web browser. More than of internet users prefer it for their daily browsing and development. Google Chrome 65% , like other browsers, has developers tools, which help developers and testers in development to test and debug processes. Chrome What any that works with needs to know: QA Engineer web UI Reading logs from (logs, warnings, errors). Console Running code in console. JavaScript DevTools Using tab to see what requests your web application sends to your server (websocket messages would be a huge plus). Network API Using tab to navigate through tree, modify it and create selectors (XPATH, CSS) for your tests. Elements DOM UI So this final paragraph is actually not just for , but it's also a for manual . Test Automation Engineers must-have QA Engineers Thanks for reading, I hope you've learned something new and now know what to improve if you're an that recently started a career in . Engineer Test Automation I also hope that it's been helpful for those that are going to hire a skilled and were looking for criteria that expose beginners. Test Automator

Google

2022 - HackerNoon Contributor of the Year - Automation

Nominated for 2022 - HackerNoon Contributor of the Year - Automation

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

5 Common Beginner Mistakes in Test Automation

Too Long; Didn't Read

Company Mentioned

Dmitrii Bormotov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

5 Common Beginner Mistakes in Test Automation

Too Long; Didn't Read

Company Mentioned

Dmitrii Bormotov

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES