Arunkumar Khannur's Software Testing Knowledge Center

9.8. User Interface Testing

In Client Server Applications, User Interfaces (UI) are the means of supplying inputs to system, establishing connectivity with back-end, and also, helping the user to work. UI components are classified into three higher level constructs, viz., Menus, Controls, and Windows.

Menus list commands available to the user. There are several types of menus, including drop-down menus, pop-up menus, and cascading menus. In these menus, during testing one has to consider:
  • Menu Titles and
  • Menu Items
Controls are graphic objects that represent the properties or operations of other objects. Here tester has to consider controls that include:
  • Buttons: Command Buttons, Option Buttons, Check Boxes,
  • List Boxes:
  • List View Controls: Tree View Controls
  • Text Fields: Text Boxes; Rich text Boxes; Combo Box; Drop-down Combo boxes; Spin Boxes; Static Text fields
  • Other General Controls: Group Boxes; Column Headings; Tab Control; Scroll Bars; Sliders; Progress Indicators; Well Controls
  • Tool Bars and Status Bars

There are different window types, we have to check for general appearance and operation. Here tester has to consider following:
  • In Primary Windows, we have to consider
    • Window components: Title Bar; Title Bar Icons; Title Text; Title Bar Buttons
    • Window operations: Activating and Deactivating Windows; Opening and closing windows; Moving Windows; Resizing Windows; Maximize, Minimize & Restore Windows; Size Grip; Scrolling Windows; Splitting Windows
  • In Secondary Windows, we have to check characteristics of Secondary Windows which include:
    • Appearance and behavior; Interaction with other windows; Unfolding secondary windows; Cascading secondary windows; Window placement; Modeless vs. Modal; Default buttons; Navigation in Secondary Windows; Validation of Input

UI Testing is Checklist driven and sample Checklist appears in Table 9.3 UI Checklist.
Interface Checklist: General considerations
Does the application have the 'look' of the Windows Interface (including, but not limited to, desktop, windows, and menus)?
Does the application have the 'feel' of the Windows Interface (including, but not limited to, pointing, selecting, and keyboard input)?
If a metaphor is being used, is it suitable for the application? Does the metaphor have a 'real' visual and behavioural representation, as with the desktop, so that the users do not have to carry a 'map' in their head?
Does the application always provide some indication that an activity is being carried out in response to a command?
Does the user always have the option of finding an object or action on the screen (as opposed to having to remember and type)?
Are the operations consistent with the standard elements of the interface; that is, if a user is familiar with standard applications, will the application seem like familiar territory?
Is a printout a replica of what the user sees on the screen (that is, WYSIWYG)?
Is suitable feedback provided during task processing? Is the completion of a processing task indicated somehow? Is the duration of the task indicated?
Is an explanation offered if a particular action cannot be carried out? Are alternatives offered?
Are there warnings about risky actions? Are there different warnings for different levels of risky actions? Are there enough warnings without being too many? Are users allowed to back away gracefully from risky territory?
Is there a feeling of stability? Are there enough landmarks to remind the user what area of the application he or she is in?
Can an operation be interrupted? Can Escape be used to cancel an operation that has a Cancel button?
Interface Checklist: Graphic design
Do the commands, features, and parameters of the application, as well as all of the user's data, appear as graphic objects on the screen (as much as possible)?
Are the graphics believable?
Does the screen look 'clean' and free from clutter?
Does the user have control over the design of the workplace, allowing him or her to individualize it?
Interface Checklist: Window standards
Does the standard state of the window seem appropriate in EGA, 4-bit color? On a larger display (VGA, 8 bit color; SVGA, 16-bit color?)
Does the preliminary user-selected state seem appropriate in EGA, 4-bit color? On a larger display (VGA, 8 bit color; SVGA, 16-bit color?)?
Does the choice made to open in either the standard or the user-selected state make sense?
Can each sizeable window be made as large as the smaller of either the maximum document size or the maximum size of the displays?
Interface Checklist: Scrolling standards
Does clicking on a scroll arrow cause the document to 'move' a distance of one unit in the chosen direction? (The unit should be appropriate to the application.)
Does clicking in the scroll bar below the scroll box advance the document by a windowful? (A 'windowful' is the height or width of a window, minus a one-unit overlap.) Does clicking above the scroll box move the document back by a windowful?
If the user drags the scroll box and then moves the pointer well outside the scroll bar, does the scroll box snap back to its original position?
Is the function of the arrow keys different from the function of the scroll bar? (Remember: all these questions should be answerable with 'yes': arrow keys should not substitute for scroll arrows.)
Interface Checklist: Dialog box standard
Is the question posed in a straightforward and positive way? For example, 'Do you want to erase everything on this disk?' rather than 'Do you not want to alter the contents of this disk?'
When appropriate, do buttons have descriptive labels, such as 'Destroy Power Supply' rather than 'OK'?
Does the default button (if any) has a bold outline around it?
Does pressing Escape indicate Cancel in a dialog box? (Pressing Escape should never cause the user to lose information.)
When a command key equivalent is used, does the button highlight?
Do modal dialog boxes not lead to other modal dialog boxes?
Do modal dialog boxes that can be moved have a drag region (title bar), as well as the outline within the content region to signify that it is a modal dialog?
Has room been left to allow the dialog box to grow during localization? Most languages require more characters than English to convey equivalent messages.
Interface Checklist: Alert standards
Do the alert icon and message fit the situation?
Does a flash (rapid inverting) of the menu bar accompany a beep alert so that people who can't hear don't miss the message?
Does the alert message not only tell the user what is wrong but also offer suggestions as to what to do to correct it?
Is this alert necessary? Often, the user can be prevented from making an error. Example: if the application cannot handle an 80 character file name, don't offer them an 80 character field in which to enter it.
Interface Checklist: Menu standards
Does the menu bar contain only menu titles?
Are the standard menus—File, and Edit —present, with at least the standard items?
Is there enough extra room to allow for the expansion that almost always occurs during translation into other languages?
Do the unique menus of the application have names that are appropriate? Are the names sufficiently different from the standard menu names? Can the user understand and remember their meaning?
Are frequently used menu items available at the top level rather than in a hierarchical menu or a dialog box? If not, can the user move them up?
When an item in a menu is currently disabled, is it dimmed in the menu rather than missing from it?
If all the items in a menu are currently disabled is the menu title dimmed? Can the user still pull down the menu and see the dimmed names of the operations?
Are the names of menu items appropriate? Can the user understand and remember their meaning?
Are menu titles and items in caps/lowercase unless there is a compelling reason to have a different style, such as 'ALL CAPS' in a Style menu?
Do menu items have an ellipsis (…) if more information is required from the user?
Do hierarchical titles in a menu have a right-pointing triangle? Are hierarchical menus used only for lists of related items?
Can the user see all the commands, items, and hierarchical titles in a menu without scrolling? Scrolling should be necessary only for menus that users have added to or for menus that spill over because the user has selected a large system font.
Is the indication of a pop-up menu a drop-shadowed box around the current value? While the menu is showing, is its title inverted and is the current value checked? If the menu must be scrolled, is this indicated by up- or down-pointing triangles?

Khannur's Book
Arunkumar Khannur, Software Testing - Techniques and Applications, Published by Pearson Publications, 2011 (ISBN:978-81-317-5836-6; Pages:341 + xxii)
Follow Khannur
Khannur's Company
ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
Khannur's Software Testing Forum
 Contact Khannur
ISQT Process & Consulting Services Pvt. Ltd.
#732, 1st Floor, 12th Main,
3rd Block, Rajajinagar,
Bangalore - 560010, INDIA
Phone: +91 80 23012511
Skype: arun.isqt