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?
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.
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.
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.
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).