Phones, tablets, laptops, desktop computers, IoT panels, gaming consoles, televisions, infotainment systems, appliances, printers, VR, AR, and almost every modern device that uses Input/Output should be tested for functionality before hitting the market and reaching the end user. Alongside the software, we also need to test the User Interface. 

What does UI testing refer to?  

UI Testing may refer to both Graphical (GUI Testing) and Command Line Interface testing (CLI Testing). GUI Testing is done when you have graphical elements displayed on a screen. It’s also known as application front-end testing. CLI UI Testing is done when you only have characters and the command line presented on the screen rather than graphical elements.  

In a broader perspective, we can also mention HMI (Human-Machine Interface), which refers to touch screens, keyboards, mice, joysticks, gamepads, sensors used for gesture or movement input, or smartwatch sensors for picking up user health condition, step counting, etc., as well as more primitive ones like switches for machinery or appliances. 

Some modern devices for VR (Virtual Reality) or AR (Augmented Reality) mostly use CUI (Composite User Interface), which engages two or more senses. 

We can define that UI Testing, in general, can be done on any device that can manage user input, even a simple pocket calculator. In other words, we can say that every input that a user gives to a device to get some result can be considered a User Interface. In this article, we will focus on application UI Testing, which is our focus in Spyrosoft. 

What UI Elements can we test? 

Radio buttons are round elements with a dot in the middle, which are used to turn on or off some of the options or features in the application. Radio buttons are also used when there are multiple choices that must not be selected at the same time. 

Buttons are the clickable (if not disabled) elements, for example, the “OK” or “Cancel” buttons. There could be plenty of buttons with distinct functions depending on the application or OS. 

Checkboxes are the rectangular elements that you can check mark. They allow selecting multiple options. 

Text boxes are rectangular frames where you can enter data. If you need to mask your password, you can adjust them in that direction. Similar elements are the text areas. 

Dropdown menus allow us to choose from various options. 

Links are the underlined blue texts holding the “URL” data. They are the most common UI elements that I am sure you’re familiar with.  

Other UI elements include images, menus, sliders, calendars/date pickers, etc. 

In the UI Testing, those elements (and many others) need to be tested to ensure they work as the Software Specification document defined them in the first place. 

In automation testing, properties and their values are used for selecting an element where you can have all sorts of commands simulating user behaviour. In manual testing, those are not of great relevance. With Load Testing, automation becomes more relevant.  

Load Testing is a simulation of multiple users accessing your application simultaneously. It would be difficult to test it manually because you’d need to involve users offline. With automation, you write a script for UI Functional Tests and then add multiple virtual users. The script is then multiplied by the number of virtual users you defined in your testing tool. 

Some of the most used automation tool commands are: Click, Wait, Check and Type, however, they may vary from tool to tool. 

The UI testing consists of checking core functionalities, the placement of UI elements, checking sizes, colours, spelling, and User Interface usability.  

If we want to consider the overall experience of a user with an application, we could speak of UX (User Experience). A good UX keeps the user coming back. Bad UX repels the user in some way and, in the worst case scenario, your application may cause undesired results. Bad UX may even result in losing a client or getting bad ratings for your product.  

On what devices should we test UI?  

In the past, most of the applications were designed for desktop computers. Nowadays, the range of devices we use daily includes laptops, mobile phones, tablets, etc. and applications are based on web browsers and cloud infrastructure. However, the basic idea of User Interfaces remained the same – to give input to the device in order to receive some output.  

Modern mobile phones and tablets use touch screens with virtual keyboards, and there is no need for a physical keyboard or mouse. Some laptops use touch screens as well. There are also smart watches, big panels for ordering food and a plethora of other devices with the I/O (Input/Output) function. 

From the software perspective, there are different operating systems currently available for use. The most common are Windows, Linux, iOS and Android, but there are also some industry-tailored ones.  

Core technologies used for producing the software are .NET, Java, JavaScript, PHP, Python, C, C++, C#, etc. Web development technologies are Angular, React JS, Node JS, Vue JS, JavaScript, Ember JS, Kotlin, Groovy, Laravel, etc. Mobile development technologies include Android, iOS, React Native, QT, Kotlin, Xamarin, Flutter, PhoneGap, Cordova, etc. Database development technologies are PLSQL, MySQL, MSSQL, MongoDB, PostgreSQL, Redis, etc. Cloud computing technology providers are AWS, Azure, GoogleCloud, etc. 

There are a lot of combinations of those and other technologies, both software and hardware. Before testing specific software, all these factors need to be considered and based on that, a testing plan should be created. 

What are the types of UI tests? 

UI Testing can be Manual, Automated, or a combination of the two. When choosing a testing method, you should consider: 

  • the robustness and complexity of the software,  
  • the impact of new features,  
  • how many QA Testers are available,  
  • the priorities and risk levels,  
  • how many environments should be tested,  
  • what devices/platforms/browsers will be used,  
  • what tools are possible to use, etc. 

For both Manual and Automation Testing, you will need Test Cases. First, you must decide how to write them (Step-by-Step, BDD Gherkin, etc.) and where they’ll be stored. You can use Excel or more specialised tools, like Zephyr Scale within Jira, Microfocus ALM Suite or any other. 

You can manually click on the UI or consider automation, depending on the tool used. Automated testing could be done just like manual testing but with a record option where you can play the recorded actions at the end. Tests could also be automated without a record option, thanks to the scripts. The scripting languages used in such cases are JavaScript, TypeScript, VBScript, etc. Programming languages that are mostly used for that purpose are Python, Java, C# and Ruby. 

What are the UI testing methodologies? 

The most common UI Testing methodologies are Smoke Testing, Regression Testing, Functional Testing and Acceptance Testing. To optimize time and resources, try combining R/F Tests (Regression/Functional Tests) for a more detailed result. If you just need a quick overview of how the application behaves prior to R/F Testing, you can run Smoke tests. 

The tests should cover the functionalities from the Software Specification document. That means you should verify the UI elements, spelling, input fields, formats, colours, consistency, etc. Also, it would be best if you created positive and negative test cases. 

If your application uses a login screen, users need to be created before testing. This is done by the system administrators or by QA Testers if they receive the database credentials. 

When we’re speaking of an Interface, we can’t forget to mention a machine-to-machine interface called API (Application Programming Interface). This Interface is composed of requests and responses. API testing is an entirely different topic, which I won’t focus on in this article. 

When testing UI, we must step into the end user’s shoes, just like we do when developing the UI. User needs should be understood well in order to meet them. You should also take the psychology element into consideration, as the UI should be intuitive. If it’s not, then it needs to be fixed because bad UI means a longer time to train a user, higher cost, lower efficiency and more frustration. Just imagine a guitar or a piano that has random keys. Many musicians would adapt to this, but learning would be much more complicated.  

Testing the login screens 

The login page looks mostly the same on all applications. That’s why we’ll use it as an example to explain what UI testing should look like.  

In the UI Testing domain, you need to verify that: 

  • The titles, labels, buttons, text boxes and links are presented as specified in the Software Specification document. 
  • The font type and size, the label size and the text are in line and do not overlap.  
  • The screen size, element size and colours are as they were designed. 
  • There are no undesired behaviours or artefacts for different screen resolutions, devices or browsers 

This kind of testing should be done manually. 

From the Functional Testing perspective, there is much more to be done: 

  • when the login page opens, the cursor should be positioned on the username input text box, 
  • The TAB button should enable jumping between elements, 
  • password input field should mask the entered characters, 
  • password boxes should not allow Copy/Paste of the password 
  • check the positive scenario – a user should log in with valid credentials, try the “enter” key for confirmation 
  • check the negative scenario – the user should not log in with partial/invalid credentials 
  • validation message should appear when one of the input fields is left blank or the character limit is exceeded 
  • check in the Software Specification document if the login screen should have the “Remember me” option/checkbox 
  • closing the browser should not log out an authenticated user 
  • verify the “Forgot Password” functionality 
  • check login with valid credentials after the password change is done 
  • check if the same user can log in on different devices/platforms at the same time.

When testing a Login page, there are also a lot of other test types that need to be performed as well. Some of these are Security Testing, Penetration Testing, Performance Testing, Compatibility Testing, User Acceptance Testing (UAT), etc. 

If your login page uses an external login authentication provider, such as Google, Azure AD or others, do not test those third-party applications. They are not in your domain, otherwise explicitly stated. There could be trouble for some tools to be able to handle external login element actions. 

In conclusion 

Whether we have an application or some other software, the UI should always be tested thoroughly.  A faulty UI can put the operator of a device and your business at risk. 

Some are wondering if UI testing can be fully automated.  

I will leave it for you to answer. 

About the author

Jadranko Kovačec

Jadranko Kovacec

QA Automation Quality Engineer