Where to begin when learning about GUI test automation?

We are finally starting to automate our GUI tests for a product I am working on.

Unfortunately, I recently became the sole QE member of the team as just a Jr. QE with very little automation experience. Thankfully, our front-end developers have been helping drive the development of the automated tests, but there is still a lot of ground to cover.

Without any more senior QE team members to learn from (or any QE members for that matter), I am pretty lost on how to approach any of this. I can write the tests, but I am having a hard time deciding what is actually worth testing and what is something that doesn’t need any GUI testing for it.

Can anyone recommend any good resources that I can read through to help me better understand where to start when identifying potential areas for automated tests?

Thank you.


Oh, I feel for you. It’s hard enough being experienced and the only test-focused team member.

I can give you some broad guidelines:

  • Start with what you have to automate - if you can’t do anything in the application unless you’re logged in, you have to automate logging in. Navigation may be another must, depending on how the application manages user sessions.
  • Look for high-value areas. If you’ve got something where the same steps are used but there’s a lot of variation (like selling items with different tax configurations), you’ve got an opportunity to set up some effective regression - especially if the application is a bit short on unit tests.
  • Look for the parts of the application that get the most use and/or throw the most bugs and/or have the least unit test coverage.
  • Start simple and try to keep it that way. It’s in the nature of any form of code to get more complicated the more you work on it. Test automation isn’t immune.

UI tests are always brittle. Kate already gave plenty of tips on deciding what to automate, there are loads more, but I’m going to just give this warning tip.

Assume that things will break often, and set expectations accordingly and don’t work yourself to death fixing the tooling. This means that some areas are not good candidates, and that others where a test is time consuming to do manually probably are your best candidates.

/edit GUI automation is tough, whenever it gets crazy, step back and find ways to put fun or sense of purpose back into it.

1 Like

Although you’ve negatively framed your current situation, to me, it sounds like you have a great opportunity to make an impact and add value where your previous peers didn’t.

The fact you’ve posted asking for direction is also positive, and shows you want to learn and care about the quality of the task ahead. Support from the developers is also a significant resource, and its not a given developers will or can always help.

To answer your question, without knowing what exactly you’re automating (GUI is a little broad) MoT is obviously a great place to start - but I’d encourage you to look at Test Automation University, look up people such as Alan Richardson and Kevin Lamping on Youtube and check out some of their work.

I echo the other tips here; Keep test small and low maintenance. Ensure each test has value, and map that out as you go. Expect walls, and expect to bypass some, but not all of them. Be creative with your automation, and have fun with it.

I hope it works out for you.


The below resource has somenthing for all types of automation and is free.
Have a look.

1 Like

One of the big things to look at with GUI testing is to look at what you are supporting - this is by way of Browser, Application, Mobile browsers and Mobile App - In addition it is worth considering the technology being used. Unfortunately this will likely define your tooling.

I have gone through many variations, Selenium, Appium. Ranorex, Cypress and Playwright, (or of course own in house test tooling).

Currently using Playwright due to being able to use Webpack, integrate with Browserstack and ease of use. (Testing Browser based products)

As mentioned previously - Look at critical path and high value functionalities (and Risk Areas). Login is essential since without it, this would be an ‘end of the road’ for the user journey. Look at core functionality and how the user interactions affect the page and journey. When I mention ‘High Value’, if an issue will result in loss of revenue / incorrect payment - that is also high risk and is essential to check. Most of GUI testing is based on ‘image and reputation’ - when looking away from functionality, decide ‘what really matters’ from a user perspective.


I believe it’s best to start from the basic concepts and best practices. And then have dinner practice.
Here is the article on three concepts: Test Automation Best Practices - testRigor Codeless Test Automation Tool

And you can practice for free as much as you’d like at https://testRigor.com with the free account.

I believe learning the concepts and best practices is what will help you to become successful at it.

Here’s a little tip from me.

Download Katalon Studio for free and have a go at automating a few tests with it. It’s pretty simple to use and get going with (essentially it is a free, pre built framework). If you have some basic understanding of html and how to define elements you can put some tests together quite quickly.

Even if this doesn’t end up being your final choice it can give you a chance to practice some of the elements of automation at least (how to create tests, the good practice).