If you work as a manual tester but want to transition to test automation, then you’ll need a few technical skills to do your new job efficiently. In this article, I’ll walk you through some one of them and explain how they will help you in this role. My main focus is on web applications, but similar concepts should apply to test automation in other technologies as well.
Git is the most common version control system in the industry. Git has a steep learning curve, but it’s well worth learning it well. It makes sense to keep the automated tests in the same repository as the application, and development teams often have very precise rules for working on a repository—the better you know Git, the easier it will be for you to follow those rules.
Branches in Git allow you to create your code change “on the side” and share it without affecting the main branch. It allows you to run your tests with continuous integration (CI) and check that everything works OK before you merge changes to the branch used by everybody else. Branches are not complicated—any Git course should cover them in the beginning.
Often, development teams have very precise guidelines on how the commit messages should be written. I definitely make sure all my colleagues use the same commit message pattern, especially:
- grammatical tense and person,
- reference to the ticket, and
- wrapping lines before they get too long.
It’s very likely that your team has some established rules as well. The best approach is to check out the Git history (with
git log or on your repo hosting) and ask your colleagues if it’s not clear.
A good and common practice is to create a pull request from your branches—in this way, the team can review and refine code before merging. Pull requests help with early detection of many issues, and if done right, they can improve readability of the repository history—especially if your reviewers pay attention to the commits that are being merged. Working with pull requests, following feedback, and integration with the ever-moving main branch can require some slightly more advanced Git operations such as the following:
- squashing or rewriting commits
Those concepts can be challenging at first, but they help a lot with everyday work in Git.
There are many tools that allow you to write test automatization for web applications. They are all based on similar concepts:
- a browser that runs your application
- a test runner that controls the application
- a script that describes actions to be done in the application and expectations
Choosing the right framework can be tricky because the more tests you write with it, the more difficult it will be to change the technology later on. Luckily for beginners, this decision has most likely already been made by the time you join the project, so you can just focus on using the tool correctly.
Writing automated tests is programming—even if it’s focused on a very specific use case. As you spend more time doing automation, it will help you to improve in the following areas.
Most web applications are written in JS, and it’s very likely that your tests are written in JS as well. Knowing the basics of JS will be useful for:
- troubleshooting issues in the test code you are writing, and
- understating the application code enough to know how to mock its parts.
Concepts that will often help you achieve this:
- syntax and automated syntax checkers—for example, ESLint
The web application you test is displayed as HTML. To program the interaction and expectations, you will need to understand the DOM tree and how to operate on it. In many E2E frameworks, you use CSS selectors to pick the right elements in your test. So, some basics of HTML and CSS will definitely be needed to work efficiently on test automatization.
You can sign up here to get updates when I publish new content about testing or other topics related to programming. Meanwhile, here you have articles on related topics: