I’m not entirely sure “unbloating” is a word. In fact I’m 95% sure it’s not. Regardless of that, this is about taking those huge, automation packs for the UI and chucking them in the bin as soon as possible.
So, let’s examine the biggest issues with UI automation packs first.
Maintainability
Even with the best CI system set up in the world, the creation of new UI tests can only be pushed so far left. Although the tests themselves can be created as skeletons and even the basic structure and commands, you need to have the components there to finish off the tests and ensure they run as expected. Naturally the UI tests will lag behind the product creation to some extent, which means it’s always a game of catch up. Invariably this means that the UI pack is failing more often than not and failures become commonplace. This leads to not being able to trust the results, whether they pass or fail which means that the pack is ultimately not adding any value.
The ultimate catch all
I think the biggest issue I have with UI automation is the way it is often used as a catch all for covering various risks and issues that should be covered earlier on in the process. The UI pack is often the last to run and the longest pack meaning the feedback loop for any issues is quite large. A lot of scenarios can (and should) be covered further down the stack closer to the code. I’ve seen UI automation used on many occasions as the first place to start adding automation to a product, rather than thinking about a targeted automation strategy and looking to push the automation closer to the code.
Separation of roles
It’s very common to see UI automation separated from the product code in its own repository. While this can have some benefits, the big disadvantage for me is that is makes it seem like a separate task and this does not lend itself to creating the tests as part of a normal feature lifecycle. I also believe that this often leads to developers not getting as involved as possible in the UI test pack.
When automation is part of the product repository and runs when the product builds, it’s easy to encourage people working on the product to create and maintain that automation. If it’s separate and/or in a different language, it’s harder to do this.
My proposal
Remove all the UI automation! Think of that as the crazy goal. Maybe it can’t be achieved, but it can certainly be optimised by reducing the scope and size of UI automation. That’s the aim…now let’s see some ways we can get there…
Push the automation down the stack
This is the biggest one. It’s so common to cover scenarios and functionality at the UI level because it’s not covered elsewhere. Look at the layers of automation you have and examine what your boundaries are at that layer. Have you tested all the enclosed pieces of logic at the unit level? Can you ensure more possible data scenarios and flows through component or integration tests? Are there UI flows that are basically just strings of API calls that could be covered at that layer?
Make a dumb UI
If you are pushing automation down the stack, you can cover most of the functional scenarios and data scenarios. However you will still need to cover the presentation of the data to the user somehow. But rather than a bulky UI automation pack, can you cover some of this in the component testing of the UI? To do this, it helps if you have a simple UI which simply calls endpoints and presents data from those endpoint. Almost all modern languages have excellent automation frameworks allowing you to cover the UI component now. You can write components tests to check the external endpoint connections and contracts and you can write ones to cover how that data is then presented. However if you have a bloated UI with lots of server side logic then it will be very hard to do this.
Introduce continuous testing
An important part of having a good automation strategy is having the automation running as part of a CI system. This way all the automation you introduce at any level will automatically be providing feedback for you. A number of times I have seen CI systems which do not run any automation or ones that some automation but don’t report on it. The result of this is that confidence in the automation is not as high, meaning scenarios get added to the UI automation instead to increase the confidence.
Concentrate on user journeys
A UI pack can easily become bloated by adding defect or edge case scenarios when this logic could be covered elsewhere. One way to ensure you don’t do this is to concentrate on making the scenarios your UI pack covers full user journeys through your system. Take the most used and high risk flows through the system and maybe cover these with a lightweight easy to maintain automation pack. Covering anything else will potentially tip the balance between time and effort to maintain and risks covered the wrong way.
Conclusion
There are absolutely scenarios and products where UI automation makes perfect sense, but it’s hugely overused and misused in my experience.
Removing the UI automation is an aim I always have in any test strategy as this allows faster, higher quality feedback and more time for testing. However this is an aim and it’s not always possible or the right thing to do for the situation.