Kodziak

Starting Test Automation: Language, Tools, First Tests

Posted on Updated By

Starting with test automation is rarely smooth. I had a pile of questions when I began:

  • Do I have to be a manual tester first?
  • What language should I start with?
  • What framework or library should I pick?
  • What should I automate first?
  • Where do I look for answers?

I’ll answer each one based on what I did when I started with automated functional tests. My situation was:

  • some experience with manual testing,
  • no programming background,
  • a team that wanted to start with test automation,
  • a business already convinced it would pay off.

Read everything below with that in mind.

Do I have to be a manual tester first?

Not strictly, but it helps a lot.

I started as an intern manual tester and moved to a junior QA position soon after. For about half a year my whole job was running manual tests. Then I switched to automation, because I knew a chunk of the regression cases could be automated, which would free up time for testing new features. I still think regression is the best place to start. It saves time on new features and shortens time to market.

If you are wondering what a QA engineer is expected to know beyond this, see Who is a QA engineer and what should they know.

Manual testing also teaches you to write a good test case, and that skill carries over directly. You check specific elements and behaviours by hand, so you know what a useful automated check looks like. If you skip that part, you’ll have to catch up on it later, on top of everything else a beginner has to learn.

What programming language should I pick?

It depends, but my default answer is: the one your teammates already use.

Say you work in a scrum team that writes front-end applications, and you have to write UI tests with no programming background. Pick the language the developers know. They can help you set up the architecture and write the first test. Problems come in all sizes: the framework misbehaves, a variable isn’t passed, the syntax is wrong, an if is backwards. Having people who can look over your shoulder for any of those is worth a lot. And for a developer, learning a new test framework is usually easy.

There’s a second payoff. Once the tests are in a language the team knows, anyone can touch them. If a developer’s UI change breaks a test, why shouldn’t they update it? After walking through the scenario they could write a whole new test. That spreads knowledge, and it means you’re not the only person who can maintain the test base.

Which framework or library should I use?

That follows from the language. These are the combinations I know, with links to the docs:

In 2020 I would have listed Protractor for Angular projects. Don’t pick it now. The Angular team ended long-term support for Protractor in September 2023 and points to Cypress, Nightwatch, WebdriverIO and Playwright as replacements. Today Playwright is where I would start with JavaScript or TypeScript. I cover the setup in the Playwright tutorial.

Selenium works with almost any language. It also has a big practical advantage for beginners: nearly every problem you’ll hit has already been answered on StackOverflow.

What should I automate first?

Regression tests. They’re repetitive: you run the same cases again and again, it’s boring, and it takes anywhere from a few hours to days. Automating them frees that time for testing new features and shortens time to market.

They also don’t change much. You won’t rewrite half of them on every deployment, so they need little maintenance.

The business case is easy to make. If regression takes two days by hand and an hour once automated, that’s a strong argument for starting automation. An hour is still long, though. With parallelisation and similar techniques you can get it down to a few minutes.

My pick for the very first test is login. It’s repeatable, everyone knows how it should work, and it’s not hard. When you start writing selectors, read how to make UI tests resilient to changes first.

Where can I find information?

Start with the official documentation linked above. Beyond that:

The last three are aggregates of tutorials and general articles. In practice I mostly use the first one. Whatever error I paste into Google, a StackOverflow answer comes up first.

Summary

  • Do I have to be a manual tester first? Very helpful, not required.
  • What language should I start with? The one your team knows.
  • What framework or library should I pick? Whatever fits that language, see the list above.
  • What should I automate first? Regression tests, starting with login.
  • Where do I look for information? The docs, then Google and StackOverflow when something breaks.

This is my opinion, based on my own experience. If I started again under the same conditions, I’d do the same. Adjust it to your business, your kind of work and your situation.

Have a nice day!