UI Testing - Understanding the Automation Testing Pyramid (Part I)

UI Testing - Understanding the Automation Testing Pyramid (Part I)
Steve Beck
Test Automation Engineering Lead

The Automation Testing Pyramid is something we use to describe the most effective and efficient way for just about any business wanting to use Test Automation for quality assurance. You can read more about the pyramid and why we use it, by clicking here.

Following on from my article series on API Testing, this article (in two parts) will discuss the virtues of UI (or Interface) Testing: what it is, what it’s used for, and why it’s important.

What is UI Testing?

UI Testing, as the name suggests, is literally testing at the UI or interface layer of your application. In other words, the same interface your clients use to access your application.

If you’ve implemented Unit Testing and have a high degree of coverage, as well as most of your APIs with both functional and non-functional testing, then the risks remaining shouldn’t be business logic, or data risks, but rather the client-facing component. At the UI level we’re looking to find out:

  • Can a user actually use my website or application, can they navigate through it?
  • Are all the buttons going to work, or will a button stop me from doing something?
  • Does my application function as expected?

At the end of the day, if a bug on the UI is going to stop a user from doing something, it doesn’t matter how well your business logic works or how well your APIs work, the application or website is broken. It’s a minor detail which is actually one of your biggest risks, because if that Submit button doesn’t work, it doesn’t matter how clever the rest of your system is, it’s effectively useless to the end user – your client, and source of revenue.

Something so small – and something you can easily overlook – can completely overshadow everything you’ve done up to that point because your front end is the gatekeeper for the entire system. That’s how your users interact with your software.

Why do UI Testing?

UI Testing is the most brittle, unstable and slowest form of testing. So why do we still do it?

  • It’s such a big risk. If something doesn’t work on your UI, your entire application is broken.
  • It’s comprehensive. UI Testing covers all the things on the front end – making sure all the elements of the UI work like they’re supposed to. It also tests for the rules you’ve set for the UI. For example, if you’ve designed a form and don’t want users to put symbols in the form fields, there has to be a test to make sure this is flagged.
  • It’s automated. Remember we’re talking about Test Automation, the purpose of which is to automate what a manual tester would have been doing via the front end. So we want to automate as much as possible away from the front end to reduce that burden of manual testing. You don’t want to waste a manual tester’s time and make them go through every field.
  • UI Testing is done from the point of view of the user. There’s a misconception that when you automate it’s going to be done by some magic process in bulk. When we do a UI Test, we are emulating a human. It’s just running faster because the computer doesn’t have a delay in its thinking process, it’s just ticking off steps in a script. We’re covering a subset of what a human tester would cover but doing it faster.
  • One of the main focuses of UI Testing is regression testing. We create a regression pack and make sure your system is working properly after each feature release or update. The focus of the UI test is to make sure humans are able to use the application, and that there are no issues when they do so.

The goal of UI Testing is to cover the risks associated with being able to navigate through the application and being able to do the processes at a high-level, as well as all the monotonous individual component testing.

In Part II of this article, I’ll discuss some of the misconceptions around UI Testing, and things to consider in your UI Testing strategy.

Steve Beck
About Steve

Stephen Beck joined Inspired Testing in 2016 and has worked as an Automation Tester, Trainer, Team Lead and Delivery Manager within the Cape Town Delivery Centre. He has worked to provide Automation Testing solutions for multiple clients, as well as overseeing project delivery. He has also worked on creating, maintaining, and updating the tools used by Inspired Testing to ensure that clients are provided with effective Test Automation solutions.

Tagged under