User Interface testing basically means testing the UI by considering parameters such as consistency, usability, visibility, accessibility and compatibility.
Many developers have a tendency to place too heavy an emphasis on the functional aspects, underlying structure and technical brilliance of software.
However, and we all know this to be somewhat true, most users are blind to the underlying aspects of software and wholly unconcerned with it. The user will typically only see what the software does, not how it achieves the result.
Most users are only concerned about how the software will help them get their regular job done, and how pleasant it will be to work with.
In a way, the user can not be blamed for this attitude. The user interface is the only thing that most users will ever really see and use in a typical application, so a small problem in that small part could effectively render the whole system unusable for a ‘regular user’. For example, a single minor CSS problem or typo in the HTML login form could prevent users from logging in to the system. Any brilliant coding and database work beyond that point is rendered completely moot if the user can’t reach them through a fault in the UI. This is why User Interface Testing is so important.
Problems in the UI are often easy to fix if they are discovered early in the development, but they can prove to be quite embarrassing. Of course, if they are not discovered early on, they will become extremely expensive to fix.
Of course, UI testing is not always so simple, and it does require some work. You should start by thinking of UI testing as ‘testing the product’s GUI to ensure it meets written specifications’. Obviously, you will need a variety of test cases.
To generate a comprehensive set of test cases, test designers must ensure that their suite covers all the functionalities within the system as well as be sure that the suite fully exercises the GUI itself.
There are two stumbling blocks here; one is dealing with domain size and the other is working with sequences.
The problem of domain size is obvious and easy to understand. Unlike a command line interface system, a graphical user interface has a large variety and variance of operations which all need to be tested. Even a relatively small application such as Microsoft WordPad was famously said to have 325 possible GUI operations.
The second problem to be dealt with is the sequencing problem. Some of the functionalities of the system may only be accomplished after following a complex sequence of GUI events. For example, to open a file a user might have to click on the File Menu, then select Open, use the dialog box to specify the file name, then focusing the application onto the newly opened window. Obviously, the higher the number of possible operations the larger the sequencing problem will grow, and it can become a serious issue when testers are constrained to creating test cases manually.
However complex UI testing may seem to be, you can not really do without at least some form of testing, even if not of all functionalities. One way to make sure you cover as many of your bases as possible is to automate any key business scenarios from end-to-end and test them heavily, obviously prior to the release. Making sure that the most important functions of the GUI work before the release is a necessity, and if carried out well, may end up saving you and your team a lot of embarrassment.