Today's rapid random ramblings - Completely about the art (rather, artistry) of UI testing. Well, why do I call it the artistry of UI testing? To term it simply, it is an art. Spend a few minutes thinking about it - dont you feel that it's similar to how Sachin wields his bat, or Federer wields the tennis racket ? UI testing is simply an art, mainly due to the various kinds
of scenarios that you can come up with while you indulge yourself in the "art of UI testing". Nothing gives me greater pleasure than UI testing, but nothing gives me greater pain since every tester thinks of himself as a UI tester.
To understand more about my take on UI testing, let's try to define UI, before understanding "UI Testing"!!!
Definition of UI
An interface with which the end user can connect to the system/applications.
Well, in an earlier world, this was known as GUI (Graphic User Interface). The success of Microsoft Windows the world over has made it unimaginable for our current generation to even imagine a non-graphic user interface.
The way I see it, the best way for UI testing would be to create different classifications of testing and plan the test cases accordingly. My take on UI testing would be to classify UI testing as 1 of the below:-
Accessibility, Alignment, Appearance, Compatability, Data Validations, Date field validations, Error Handling, Hot Keys, Menu Validation, Application navigation, Security, Style sheet validation, Toolbar related scenarios, UI related scenarios and All other validations.
Before I proceed further, UI testing will be completely different for windows applications and web applications. This is mainly because, a windows application is completely owned by the development team, while a web application UI is somewhat dependant on the browser. For example, I will be able to write an application and have total control of it's UI if it's windows-based, but I will have to keep in mind the browser specifications while thinking of a
web-based application. Some of the items applicable for windows is not applicable for web and vice versa.
Now, before you proceed learning, please keep in mind that I subscribe to the same thought works as that of the fake tester and that's how this list has come up. This list is always debatable.
If you know Ratatouille, you would agree with him when he says "Anyone can cook". Likewise, the truth is that "Anyone can test"!!! Really, I mean it. But, again, like how cooking is an art which has been perfected over years of practise, testing is also an art which has to be practised before it can be perfected. As initial steps towards this journey, let's take a good look at the A's of UI testing.
What are the A's? -- Accessibility, Alignment and Appearance :).
The way that I define accessibility - in layman terms, the applications should contain the ability to allow everyone to access the page (even a blind person). If there is an audio output in the page, the application should have the capability to allow the deaf to be able to hear it when they access the application. For example, some users would be color blind too. That would mean that the colors (green, red, etc.) should not be used for highlighting purposes in the screen.
Alignment is the alignment of the screen and whatever you see on the screen. Now, using the browser, it would be possible for you to increase the font. Using the windows properties, it would be possible for you to change the screen resolution. Whatever be the reason, the expectation is that the application alignment is not changed and remains the same. It would be a good idea for the user to check for constant spacing across the application.
How does the application appear on screen? That is what is the meaning of appearance. Check for the size and font of all command buttons, all radio buttons, etc. used across the application.Check headings, the beginnings of the list boxes, beginning of paragraphs to ensure that whatever is given here makes logical sense.
While we are on the topic of UI testing, to answer 1 common question - is it a good idea to automate UI testing? Yes it is (more of it on another day)... But, 100% reliance on the automation process for testing the UI is a bad idea. You would need a person to test the UI.
To summarize, While it's true that whatever you do with the UI becomes, in 1 way or the other, a UI test case, it's imperative that the tester would need to understand the different classifications of UI and try his testing cases accordingly. Every tester who does not do this, in my opinion, a true "fake tester" :)!!!
See you later...