Why So Many Clicks And How Can Testing And Automation Help?
Many years ago, back when I worked for a telecom company, we were building what we called a test automation platform. It was more than what we currently call a test tool; it was a system in which we could write and execute concurrent test scripts across multiple telephony interfaces. It was extraordinarily interesting, but often infuriating, work. We configured and executed everything via the command line which gave us and our users great flexibility but was inconvenient with respect to typing (yes, we knew about command history, scripts, and aliases). This was on Unix, specifically, HPUX.
Eventually, due to business needs, we added Windows to the company’s tech stack. Along with that, we added staff that had most or all of their experience on Windows, which generally meant they spent more time with GUIs than the command line. Not that there’s anything wrong with that; it was just a different environment.
At that company, I worked for this guy called Patrick (hello, my friend, in case you are reading this!), who was a great test engineer and a great leader. We’ll get back to him in a minute.
As part of updating our testing platform and making it more user-appropriate, we created a GUI for test script execution. By this time, we’d switched the test automation language to Java and we were using Eclipse as our de facto standard IDE. Since Eclipse allowed custom plugins, we thought it was natural to create an Eclipse plugin to handle our script configuration and execution: if we’re creating our automation code using Eclipse, how convenient would it be to just run it from the same interface? Killer, right?
We gave Patrick a demo and he was impressed. He then gave us a challenge: make it so users can run test scripts in 5 clicks; at that point, it took us 7 or 8 clicks because we needed to set several values for the test scripts to run. So, we got to work. We created some reasonable defaults, changed the workflow a bit, and got it down to 5 clicks. Patrick was so impressed that he challenged us to get the number of clicks down to three. THREE!!! That took some effort, but we did it! If users used all the defaults, they could run a suite of test scripts with just three clicks!
Why does the number of clicks matter? Because I, and I suspect you, feel the effects of this every day. Click this. Click that. We need so many clicks to get logged in, to buy a product, to start doing our jobs.
So, why so many clicks?
Yes, of course, context matters; the more steps we have in a workflow, the more likely we are to need to click on more widgets. Sometimes, to provide the appropriate results to our users, a specific number of clicks is required. In other cases, not so much. But that’s not what I’m talking about here.
A great example of “Do we have too many clicks?” is the grocery chain that I typically visit. This chain offers two kinds of weekly discounts: the one that everyone gets and the one that you only get if you click the “online deal” button on their app. When I get to the checkout counter and scan in all my items, I see the “everyone gets it” discounts as I scan (this is similar behavior to when a cashier scans my items). When I’m done scanning, I still don’t see my “online deal” discounts. In order to see those discounts, I have to click the “pay now” button. When I click that button, the “online deal” discounts are displayed so quickly that I can’t verify them all. So, what do I do? I have to click the add more items button. Doing that returns me to the previous screen where all of the discounts are displayed. My next step? Once again, click the “pay now” button. It’s enough to make one scream!
Yes, having lived as a developer for many years, I’m sure the development team can explain in detail why this works this way. I suspect (with no proof at all) that the “everyone gets it” discounts are loaded into the “local” systems while the “online deal” discounts are batched up to a call to a remote system to determine which online deals I pre-selected. Don’t get me started on all the clicking I have to do to obtain messages from my health provider’s app.
Is this the kind of experience to which we aspire? Probably not. As testing professionals, it’s incumbent upon us to report observations of situations that put the quality of our products at risk; wanting to scream at the app is an indication of a product at risk. Similarly, since test automation is in support of testing, we as automation professionals need to observe how many clicks are required to automate a specific task.
Automation professionals may have an advantage in checking the number of clicks. Perhaps we can automatically count the number of clicks and then write them to a log file. Better yet, if we have an expected maximum number of clicks, we could raise an error to fail the test script if that number is exceeded, meaning that if additional clicks are added to the flow, the automation can flag if the maximum is exceeded.
I’ve lost touch with Patrick over the years so I can’t verify this, but in hindsight, I don’t think the specific number of clicks mattered to him; no one would have been fired if the most appropriate answer was “We need four clicks; three won’t provide the experience most of our users need”. Instead, I believe his actual challenge was closer to “Let’s make the GUI require as few clicks as possible for most of our users”. We, as testers and automation creators, need to think similarly about clicks and other “possible user irritants”. If our users get too irritated, there is a risk that they may choose to abandon us. It is our obligation to report these kinds of risks in addition to reporting features that don’t behave as expected.
Like this? Catch me at or book me for an upcoming event!
