First steps with UI test automation

Posted on:November 26, 2020

Starting your test automation journey isn’t always as smooth as it should be. You may have a lot of questions like:

and probably many more. I’ll try to answer all of them based on my experience and the steps I took when I started with automated functional tests.

So my case was:

And I’m going to write this article from that perspective.

Do I have to be a manual tester before?

The short answer is: it would be helpful.

I started my adventure as an intern manual tester and after quite a short time I moved to junior quality assurance position. The whole job was to perform and execute manual tests. I was doing it only for about half a year and then decided to go with automation. I knew that some regression cases could be easily automated and give me more time for other tests. And in my opinion it’s a good place to start with automation. It will save you a lot of time for testing new features and probably shorten your time to market.

When you start with manual tests first, you’ll most certainly learn how to write a good test case which is a very important skill. I mean, doing it manually you’re checking specific elements and behaviours of the application so with this knowledge it would be much easier to write good automated tests. If you skip the part of being a manual tester, you will have to catch up – so another topic for beginners:)

That’s why, in my opinion, it is important and could be very helpful to start as a manual tester, learn how to test, and then start with automation testing.

What programming language should I pick?

Like everything, it depends. When starting with test automation it’s good to have buddies in the team who could help you. It’s possible if you’re writing tests in the same language as they’re using. I started like that and in my opinion this is the best way.

So, you’re working in a scrum team, you’re writing front-end applications and you have to write UI tests without a programming background. Having those prerequisites, I would go with a language that my teammates know. Especially in the beginning, they could help you to set up the architecture and write the first test. From a developer’s perspective, learning how another framework/library works is kinda easy. And problems we could face may vary – a problem with framework and a variable not being passed, bad syntax or wrong if statement. Having a bunch of people that could help you in those situations is priceless.

Another nice thing is that the whole team could write test scripts. We are all working to make the application as good as we can, so why couldn’t a developer update a test script after it was affected by his/her changes to UI. And having gone through a given test scenario, he/she could write a whole test. It would speed up our work and let us exchange knowledge. It’s very beneficial when you’re not the only person who can maintain the test base.

We all want to have a bug free product (and we all know it’s impossible).

What framework/library?

Of course it depends on the programming language you have chosen. Here are the most popular solutions and combinations which I know (together with links to documentation):

You can notice that Selenium gives you the opportunity to write in almost any language you want. And overall it’s a nice solution with another big plus: most of the problems you’ll face with it have already been solved on StackOverflow, which is very helpful in the beginning.

What to automate first?

I’ve already mentioned manual testing and regression. As we all know, regression is kinda repeatable. Many times, we’re doing the same cases all over again which is quite boring. Also, it requires quite some time: sometimes a few hours, sometimes days. So if we write all the cases as automated we could save a lot of time for feature tests and reduce time to market.

Regression test cases aren’t very dynamic either. I mean, we probably won’t be changing half of the tests by deployment. They don’t need much maintenance time.

Reduced time to market is also an important thing related to automated regression testing. Doing it manually could take, for example, two days, and when we switch to automation, we could make it, for example, one hour. It’s very beneficial for business, which could be an argument for starting the automation. And one hour is still a pretty long time, in my opinion. Using parallelization or other techniques we could shorten it down to a few minutes. But it depends – of course.

So I would start with regression and probably with login test cases. It’s repeatable, well-known and not so hard.

Where to search for information?

I would stick to the official documentation, which is linked above, but you can also use:

There are two aggregates of links and general websites which could be helpful. Honestly, most of the time I’m using the first two ones because typing any problem into Google will probably return a solution from StackOverflow.

Summary

I hope I answered the given questions, but let’s sum it up:

It’s just my opinion based on my own experience. If I had to start with automation again, I’d do the same, with those prerequisites. But of course – you have to adjust these steps to your business, type of work, and the situation you’re in.

Have a nice day!