Take a look at what Virtuoso does at the heart of its software: functional UI testing.
We’ve gotten really fancy lately with our API testing and Live Authoring capabilities, but it’s good to go back to basics and check in on what we do at our core: functional UI test automation. This kind of testing sits right at the top of the testing pyramid, which we have here with our very cute bots helping to present!
So, functional UI testing tests a slice of functionality to ensure it works properly. It’s all about the UI, or User Interface, also known as the GUI. It sounds simple enough, but there’s a lot more to it. It’s a kind of black box testing, which means that the application under test (AUT) is tested without the tester knowing the code. Hence the name: you can’t see inside a black box. When a tester manually tests an AUT and discovers something it shouldn’t do, they only know that there is a bug, not why it’s there or how to fix it.
Bare bones, this is what functional UI testing is: based on what the system is supposed to do, it tests compliance against the requirements and then verifies them by checking against design specifications. Each time a functional UI test is performed, it tests a slice of functionality on its own.
There are two types of approaches to take: testing based on requirements and testing based on business scenarios. Testing requirements contain all the specifications that the application has to meet to form a basis to start testing from. Business scenarios focus on how the system will be perceived from a business process perspective. Basic requirements focus on individual tasks that need to be performed on the application while business requirements focus on end goals like getting a customer through the checkout process.
Let’s focus on the UI itself. The UI involves everything that a user would interact with or see like graphics, buttons, text boxes, drop-down menus, colors, fonts; quite literally everything on the front-end. There are five categories that get checked by UI testing:
Within these categories, there are also certain test cases that should be on every QA’s list, and we’ll look at some of them here: Type-ahead is important for having dropdown lists, as it allows users to type the first letter of a selection and jump straight to it instead of scrolling through dozens, sometimes even hundreds of options. Functioning progress bars also let the user know that the application hasn’t frozen and is indeed working at something. Confirm action buttons confirm whether a user wants to save or delete something that they’ve done. These instances are vital to test because if a website is frustrating to use, a user could abandon ship and go somewhere else.
There are also test cases that make things easier for the owner of the application, like data type errors (letters can’t be input into a field that should only accept numbers), field widths (a field has a functioning character limit), and error logging (the application records the details when it experiences an error). These ensure that the application is being used for its intended purpose and that users can’t break into website pages that should be private or password-locked.
Ideally, developers should not be testing their application - an idea that we’ve expanded upon before - so that means that a QA team is vitally important. Because they don’t know how the code works, they can test the application like a user would. Sound familiar? That’s exactly the idea behind black box testing. It’s easy to test something when you like exactly how it works - like proofreading your own writing (a problem I’m familiar with): you know what it should say, so it’s possible to skip over missing words and look through typos. You understand a concept, so even though you write out an explanation that makes sense to you, it might not make sense to someone else. When QA tests an app, they can find those typos (bugs) and confusing explanations (navigation issues).
There are two main approaches to testing: manual and automated. Of course, you can break it down further than that, but those two would be at the top of the chart. Automated testing can make the overall testing process much quicker and allows for continuous testing. The main advantage of manual testing is that what we just saw above: the app can be tested like a user would test it.
However, this shortcoming can be overcome by automation tools that use AI and ML. With smart automation tools, the software can learn how to test the app like a user and still execute black box testing since it doesn’t know the app’s inner workings. Codeless tools like Virtuoso can make the automation process even faster, and our smart bots test every inch of your web app with exploratory testing. Book a demo with our awesome team to see Virtuoso’s smarts in action!
