How do you choose whether to use automated UI testing vs manual UI testing for a new web application being developed for the first time? For automated UI testing I am talking about using test automation frameworks such as Selenium in which you write code to simulate user interaction with the GUI (user clicks and data entry). Should you use automated testing from release 1 when the product GUI and features are not yet finalized and users may ask for UI changes? Or do you do manual testing for the first few releases until the product is stable and then do automated testing? Any good practices or guidelines for when and how to make that choice?
There are a few questions you can ask yourself to inform your decision better:
If there aren't a lot of users using your web app, then you should focus your efforts on either building out critical features or acquiring new users.
If there aren't a lot of features to test, then it should be quick to make sure you aren't accidentally breaking any existing features when you commit new code.
If the impact when something breaks is not severe, then you can tolerate some bugs if it means you are pushing the business forward without too many regressions.
It can be easy to underestimate how much work is involved with automated testing. It can be easy to set up your first few automated tests, and it even seems magical in the beginning. But, you end up having to develop and maintain your automated testing framework. There is also a maintenance burden of maintaining your automated tests (can be flaky or change often).
When you reach a stage where your product becomes critical and any downtime can really impact the customer, you can start building out a lean automated testing framework with tests for the critical paths.
Agree with Charlie - it all depends on the life expectancy of the UI code you are writing. If it has no users and pivots are likely, there's no real value in adding UI tests. When you serve millions of users, tens and maybe hundreds of developers are working on the same code base, and regressions are harder to detect (for the simple reason that not all developers are experts at the product behavior anymore), automation is great and enables faster development because it allows developers to be confident in their changes.
That being said, there are actually several different types of UI automation (from simpler, unit-test-esque screenshot tests designed to test UI rendering and simple interactions to heavier end-to-end browser tests like Selenium). The heavier the tests are, the more cautious you should be about implementing them.
I fully agree with Charlie. He’s completely right.
I’m currently leading an UI automation effort in addition to my dev project. Here are some of my take aways :
It depends on how mature the product is, have they finalized the design, and only adding new features or are they still updating the UX Design. As with tools like playwright, if the UI devs have not properly identified the locators, they UI test will fail each time there is a design change.
Can you do a combination of API and UI tests, build out a basic UI setup, call this setup via an API, and UI test core functionalities.
What is the composition of the team? Are devs expected to write end to end tests or is there a dedicated SDET team for the same.
How do you choose whether to use automated UI testing vs manual UI testing for a new web application being developed for the first time?
With very few exceptions, it's not worth it having automated tests on a brand new front-end application (web, Android, iOS, PC/Mac app, etc):
That strategy around dogfooding and being customer obsessed can take you surprisingly far as well: Instagram got to 1 billion users with <10% automated test coverage across its mobile apps!
Any good practices or guidelines for when and how to make that choice?
As with many things in tech, it depends so much on your situation. I can't just say that you should just start doing it at 100k users, 1 million users, or 10 million users - It really depends. However, here's some questions to ask yourself:
I cover all this more in-depth in these 2 other discussions: