GUI Testing Guidelines

GUI Testing Guidelines, Screen Validation Checklist, Navigation Testing, Image Testing, Date Field Checks, Page Content Testing, and Links Testing.

GUI Testing Guidelines

What is GUI Testing?

Graphical User Interface Testing is absolutely essential for any application has to be user-friendly. The end-user should be comfortable while using all the components on the screen and the components should also perform their functionality with utmost clarity. Hence it becomes very essential to test the GUI components of any application.

GUI Testing can refer to just ensuring that the look and feel of the application are acceptable to the user, or it can refer to testing the functionality of each and every component involved.

Guidelines for effective GUI Testing

  • Check titles for all screens
  • Check all text on the window for Spelling/Tense and Grammar.
  • Use TAB to move focus around the Window and Use SHIFT+TAB to move focus backward.
  • Tab order should be left to right, and Up to Down within a group box on the screen.
  • All controls should get focus – indicated by a dotted box, or cursor. Tabbing to an entry field with text in it should highlight the entire text in the field.
  • Never updateable fields should be displayed with black text on a gray background with a black label.
  • All text should be left justified, followed by a colon tight to it. In a field that may or may not be updateable, the label text and contents change from black to gray depending on the current status.
  • List boxes are always white background with black text whether they are disabled or not.
  • In general, everything can be done using both the mouse and the keyboard. All tab buttons should have a distinct letter.
  • Clicking with the mouse on the check box, or on the text should SET/UNSET the box.
  • If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots. All Buttons except for OK and Cancel should have a letter Access to them.
  • If there is a Cancel Button on the screen, then pressing should activate it. If pressing the Command button results in uncorrectable data e.g. closing an action step, there should be a message phrased positively with Yes/No answers where Yes results in the completion of the action.
  • Pressing the Arrow should give a list of options of a List box. This List may be scrollable. You should not be able to type text in the box.
  • Combo Boxes should allow text to be entered. Clicking Arrow should allow user to choose from list
  • List Boxes should allow a single selection to be chosen, by clicking with the mouse, or using the Up and Down Arrow keys. Pressing a letter should take you to the first item in the list starting with that letter.

Screen Validation Checklist

Aesthetic Conditions:

  • Is the general screen background the correct color?
  • Is the field prompts the correct color?
  • Are the field backgrounds the correct color?
  • In read-only mode, are the field prompts the correct color?
  • In read-only mode, are the field backgrounds the correct color?
  • Are all the screens prompts specified in the correct screen font?
  • Is the text in all fields specified in the correct screen font?
  • Are all the fields prompts aligned perfectly on the screen?
  • Are all the field edit boxes aligned perfectly on the screen?
  • Are all group boxes aligned correctly on the screen?
  • Should the screen be resizable?
  • Should the screen be allowed to minimize?
  • Are all the field prompts spelled correctly?
  • Are all characters or alphanumeric fields left justified? This is the default unless otherwise specified.
  • Are all numeric fields right justified? This is the default unless otherwise specified.
  • Is all the micro-help text spelled correctly on this screen?
  • Is all the error message text spelled correctly on this screen?
  • Is all user input captured in UPPER case or lowercase consistently?
  • Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
  • Assure that all windows have a consistent look and feel.
  • Assure that all dialog boxes have a consistent look and feel.

Navigation Conditions:

  • Can the screen be accessed correctly from the menu?
  • Can the screen be accessed correctly from the toolbar?
  • Can the screen be accessed correctly by double-clicking on a list control on the previous screen?
  • Can all screens accessible via buttons on this screen be accessed correctly?
  • Can all screens accessible by double-clicking on a list control be accessed correctly?
  • Is the screen modal? (i.e.) Is the user prevented from accessing other functions when this screen is active and is this correct?
  • Can a number of instances of this screen are opened at the same time and is this correct?

Usability Conditions:

  • Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.
  • Is all data entry required in the correct format?
  • Have all pushbuttons on the screen been given appropriate Shortcut keys?
  • Do the Shortcut keys work correctly?
  • Have the menu options that apply to your screen got fast keys associated and should they have?
  • Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
  • Are all read-only fields avoided in the TAB sequence?
  • Are all disabled fields avoided in the TAB sequence?
  • Can the cursor be placed in the micro help text box by clicking on the text box with the mouse?
  • Can the cursor be placed in read-only fields by clicking in the field with the mouse?
  • Is the cursor positioned in the first input field or control when the screen is opened?
  • Is there a default button specified on the screen?
  • Does the default button work correctly?
  • When an error message occurs does the focus return to the field in error when the user cancels it?
  • When the user Alt+Tab’s to another application does this have any impact on the screen upon return to the application?
  • Do all the fields edit boxes indicate the number of characters they will hold by their length? e.g. a 30 character field should be a lot longer

Data Integrity Conditions:

  • Is the data saved when the window is closed by double-clicking on the close box?
  • Check the maximum field lengths to ensure that there are no truncated characters?
  • Where the database requires a value (other than null) then this should default into fields. The user must either enter an alternative valid value or leave the default value intact.
  • Check maximum and minimum field values for numeric fields?
  • If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
  • If a set of radio buttons represents a fixed set of values such as A, B, and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the  database by other functions, which are not screen-based, and thus the required initial values can be incorrect.)
  • If a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values.

Modes (Editable Read-only) Conditions:

  • Are the screen and field colors adjusted correctly for read-only mode?
  • Should a read-only mode be provided for this screen?
  • Are all fields and controls disabled in read-only mode?
  • Can the screen be accessed from the previous screen/menu/toolbar in read-only mode?
  • Can all screens available from this screen be accessed in read-only mode?
  • Check that no validation is performed in read-only mode.

General Conditions:

  • Assure the existence of the “Help” menu.
  • Assure that the proper commands and options are in each menu.
  • Assure that all buttons on all toolbars have a corresponding key command.
  • Assure that each menu command has an alternative (hot-key) key sequence, which will invoke it where appropriate.
  • In drop-down list boxes, ensure that the names are not abbreviations/cut short
  • In drop-down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hotkey combinations.
  •  Ensure that duplicate hotkeys do not exist on each screen
  • Ensure the proper usage of the escape key (which is to undo any changes that have been made) and generates a caution message “Changes will be lost – Continue yes/no”
  • Assure that the cancel button functions the same as the escape key.
  • Assure that the Cancel button operates, as a Close button when changes have been made that cannot be undone.
  • Assure that only command buttons, which are used by a particular window, or in a particular dialog box, are present. – (i.e) make sure they don’t work on the screen behind the current screen.
  • When a command button is used sometimes and not at other times, assures that it is grayed out when it should not be used.
  • Assure that the OK and Cancel buttons are grouped separately from other command buttons.
  • Assure that command button names are not abbreviations.
  • Assure that all field labels/names are not technical labels, but rather are named meaningful to system users.
  • Assure that command buttons are all of similar size and shape, and same font & font size.
  • Assure that each command button can be accessed via a hotkey combination.
  • Assure that command buttons in the same window/dialog box do not have duplicate hotkeys.
  • Assure that each window/dialog box has a clearly marked default value (command button, or other object) which is invoked when the Enter key is pressed – and NOT the Cancel or Close button
  • Assure that focus is set to an object/button, which makes sense according to the function of the window/dialog box.
  • Assure that all option buttons (and radio buttons) names are not abbreviations.
  • Assure that option button names are not technical labels, but rather are named meaningful to system users.
  • If hotkeys are used to access option buttons, assure that duplicate hotkeys do not exist in the same window/dialog box.
  • Assure that option box names are not abbreviations.
  • Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas “Group Box”
  • Assure that the Tab key sequence, which traverses the screens, does so in a logical way.
  • Assure consistency of mouse actions across windows.
  • Assure that the color red is not used to highlight active objects (many individuals are red-green color blind).
  • Assure that the user will have control of the desktop with respect to general color and highlighting (the application should not dictate the desktop background characteristics).
  • Assure that the screen/window does not have a cluttered appearance
  • Ctrl + F6 opens next tab within tabbed window
  • Shift + Ctrl + F6 opens previous tab within tabbed window
  • Tabbing will open the next tab within the tabbed window if on the last field of the current tab
  • Tabbing will go onto the ‘Continue’ button if on last field of last tab within tabbed window
  • Tabbing will go onto the next editable field in the window
  • Banner style & size & display exact same as existing windows
  • If 8 or less options in a list box, display all options on open of list box – should be no need to scroll
  • Errors on continue will cause the user to be returned to the tab and the focus should be on the field causing the error. (i.e the tab is opened, highlighting the field with the error on it)
  • Pressing continue while on the first tab of a tabbed window (assuming all fields filled correctly) will not open all the tabs.
  • On the open tab, the focus will be on the first editable field
  • All fonts to be the same
  • Alt+F4 will close the tabbed window and return you to the main screen or previous screen (as appropriate), generating a “changes will be lost” message if necessary.
  • Micro help text for every enabled field & button
  • Ensure all fields are disabled in read-only mode
  • Progress messages on load of tabbed screens
  • Return operates continue
  • If retrieve on load of tabbed window fails window should not open Specific Field Tests.

Date Field Checks:

  • Assure that leap years are validated correctly & do not cause errors/miscalculations.
  • Assure that month codes 00 and 13 are validated correctly & do not cause errors/miscalculations.
  • Assure that 00 and 13 are reported as errors.
  • Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations.
  • Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/miscalculations.
  • Assure that Feb. 30 is reported as an error.
  • Assure that century change is validated correctly & does not cause errors/miscalculations.
  • Assure that out-of-cycle dates are validated correctly & do not cause errors/miscalculations.

Numeric Fields:

  • Assure that the lowest and highest values are handled correctly.
  • Assure that invalid values are logged and reported.
  • Assure that valid values are handled by the correct procedure.
  • Assure that numeric fields with a blank in position 1 are processed or reported as an error.
  • Assure that fields with a blank in the last position are processed or reported as an error.
  • Assure that both + and – values are correctly processed.
  • Assure that division by zero does not occur.
  • Include value zero in all calculations.
  • Include at least one in-range value.
  • Include maximum and minimum range values.
  • Include out of range values above the maximum and below the minimum.
  • Assure that upper and lower values in ranges are handled correctly.

Alpha Field Checks:

  • Use blank and non-blank data.
  • Include lowest and highest values.
  • Include invalid characters & symbols.
  • Include valid characters.
  • Include data items with the first position blank.
  • Include data items with the last position blank.

Manual and Automated Testing Tutorials 

1. Manual Testing Tutorial
2. Selenium Tutorial
3. Java Tutorial
4. Python Tutorial
5. SQL Tutorial
6. Manual Testing Video
7. Selenium Training Videos
8. Java Video Tutorial
9. Python Video Tutorial
10. SQL Video Tutorial
Follow me on social media:

Leave a Comment