GUI Testing Checklist

Purpose of this GUI Testing Checklist is to make sure that GUI of all the applications at any Organisation are developed and tested according to the known and understood standard. This checklist can give some guidance to the development team as well as QE team. Development team should make sure that during the development they follow guidelines related to the compliance, aesthetics, navigation etc. Onus of testing GUI is on the QE team. Appropriate defect should be raised in the <DTS> system, indicating defect and other relevant information.

This GUI test checklist will ensure that all the GUI components are thoroughly tested. This checklist is categorized according to the following sub-sections –

·         Windows compliance standards

·         Validation checklist for tester

·         Field specific test

·         Short-cut keys and hot keys

Windows Compliance Standards

These compliance standards are followed by almost all the windows based application. Any variance from these standards can result into inconvenience to the user. This compliance must be followed for every application. These compliances can be categorized according to following criteria

1. Compliance for each application
1. Application should be started by double clicking on the icon.
2. Loading message should have information about application name, version number, icon etc.
3. Main window of application should have same caption as the icon in the program manager.
4. Closing of the application should result in “Are you sure?” message.
5. Behaviour for starting application more than once must be specified.
6. Try to start application while it is loading
7. On every application, if application is busy it should show hour glass or some other mechanism to notify user that it is processing.
8. Normally F1 button is used for help. If your product has help integrated, it should come by pressing F1 button.
9. Minimize and restoring functionality should work properly

2. Compliance for each window in the application
1. Window caption for every application should have application name and window name. Specially, error messages.
2. Title of the window and information should make sense to the user.
3. If screen has control menu, use the entire control menu like move, close, resize etc.
4. Text present should be checked for spelling and grammar.
5. If tab navigation is present, TAB should move focus in forward direction and SHIFT+TAB in backward direction.
6. Tab order should be left to right and top to bottom within a group box.
7. If focus is present on any control, it should be presented by dotting lines around it.
8. User should not be able to select greyed or disabled control. Try this using tab as well as mouse.
9. Text should be left justified
10. In general, all the operations should have corresponding key board shortcut key for this.
11. All tab buttons should have distinct letter for it.

3. Text boxes
1. Move mouse to textbox and it should be changed to insert bar for editable text field and should remain unchanged for non-editable text field.
2. Test overflowing textbox by inserting as many characters as you can in the text field. Also test width of the text field by entering all capital W.
3. Enter invalid characters, special characters and make sure that there is no abnormality.
4. User should be able to select text using Shift + arrow keys. Selection should be possible using mouse and double click should select entire text in the text box.

4. Radio Buttons
1. Only one should be selected from the given option.
2. User should be able to select any button using mouse or key board
3. Arrow key should set/unset the radio buttons.

5. Check boxes
1. User should be able to select any combination of checkboxes
2. Clicking mouse on the box should set/unset the checkbox.
3. Spacebar should also do the same

6. Push Buttons
1. All buttons except OK/Cancel should have a letter access to them. This is indicated by a letter underlined in the button text.  The button should be activated by pressing ALT
2. Clicking each button with mouse should activate it and trigger required action.
3. Similarly, after giving focus SPACE or RETURN button should also do the same.
4. If there is any Cancel button on the screen, pressing Esc should activate it.

7. Drop down list boxes
1. Pressing the arrow should give list of options available to the user. List can be scrollable but user should not be able to type in.
2. Pressing Ctrl-F4 should open the list box.
3. Pressing a letter should bring the first item in the list starting with the same letter.
4. Items should be in alphabetical order in any list.
5. Selected item should be displayed on the list.
6. There should be only one blank space in the dropdown list.

8. Combo Box
1. Similar to the list mentioned above, but user should be able to enter text in it.

9. List Boxes
1. Should allow single select, either by mouse or arrow keys.
2. Pressing any letter should take you to the first element starting with that letter
3. If there are view/open button, double clicking on icon should be mapped to these behaviour.
4. Make sure that all the data can be seen using scroll bar.

Screen Validation Checklist

Along with compliance standard, aesthetic, navigation, usability etc also plays an important role in the GUI Testing and development. This checklist will help you get started with what should be tested as part of GUI testing.

1. Aesthetic Conditions
1. Is the general screen background the correct colour?
2. Are the field prompts the correct colour?
3. Are the field backgrounds the correct colour?
4. In read-only mode, are the field prompts the correct colour?
5. In read-only mode, are the field backgrounds the correct colour?
6. Is all the screen prompts specified in the correct screen font?
7. Is the text in all fields specified in the correct screen font?
8. Are the entire field prompts aligned perfectly on the screen?
9. Are all the field edit boxes aligned perfectly on the screen?
10. Are all group boxes aligned correctly on the screen?
11. Should the screen be resizable?
12. Should the screen be minimisable?
13. Are the entire field prompts spelt correctly?
14. Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified?
15. Are all numeric fields’ right justified? This is the default unless otherwise specified?
16. Is all the micro help text spelt correctly on this screen?
17. Is all the error message text spelt correctly on this screen?
18. Is all users input captured in UPPER case or lower case consistently?
19. 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.
20. Assure that all windows have a consistent look and feel.
21. Assure that all dialog boxes have a consistent look and feel.

2. Validation Conditions

a.     Does a failure of validation on every field cause a sensible user error message?

b.    Is the user required to fix entries which have failed validation tests?

c.     Have any fields got multiple validation rules and if so are all rules being applied?

d.    If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message?

e.     Is validation consistently applied at screen level unless specifically required at field level?

f.     For all numeric fields check whether negative numbers can and should be able to be entered.

g.    For all numeric fields check the minimum and maximum values and also some mid-range values allowable?

h.     For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?

i.      Do all mandatory fields require user input?

j.      If any of the database columns don’t allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

3. Navigation Conditions

a.     Can the screen be accessed correctly from the menu?

b.    Can the screen be accessed correctly from the toolbar?

c.     Can the screen be accessed correctly by double clicking on a list control on the previous screen?

d.    Can all screens accessible via buttons on this screen be accessed correctly?

e.     Can all screens accessible by double clicking on a list control be accessed correctly?

f.     Is the screen modal? Is the user prevented from accessing other functions when this screen is active and is this correct?

g.    Can a number of instances of this screen be opened at the same time and is this correct?

4. Usability Conditions

a.     Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.

b.    Is all date entry required in the correct format?

c.     Have all pushbuttons on the screen been given appropriate Shortcut keys?

d.    Do the Shortcut keys work correctly?

e.     Have the menu options which apply to your screen got fast keys associated and should they have?

f.     Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.

g.    Are all read-only fields avoided in the TAB sequence?

h.     Are all disabled fields avoided in the TAB sequence?

i.      Can the cursor be placed in the micro help text box by clicking on the text box with the mouse?

j.      Can the cursor be placed in read-only fields by clicking in the field with the mouse?

k.     Is the cursor positioned in the first input field or control when the screen is opened?

l.      Is there a default button specified on the screen?

m.   Does the default button work correctly?

n.     When an error message occurs does the focus return to the field in error when the user cancels it?

o.    When the user Alt+Tab’s to another application does this have any impact on the screen upon return to the application?

p.     Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer

5. Data Integrity Conditions

a.     Is the data saved when the window is closed by double clicking on the close box?

b.    Check the maximum field lengths to ensure that there are no truncated characters?

c.     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.

d.    Check maximum and minimum field values for numeric fields?

e.     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?

f.     If a set of radio buttons represent 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.)

g.     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.

6. Modes Conditions (Editable / Read Only)

a.     Are the screen and field colours adjusted correctly for read-only mode?

b.    Should a read-only mode be provided for this screen?

c.     Are all fields and controls disabled in read-only mode?

d.    Can the screen be accessed from the previous screen/menu/toolbar in read-only mode?

e.     Can all screens available from this screen be accessed in read-only mode?

f.     Check that no validation is performed in read-only mode.

7. General Conditions

a.     Assure the existence of the "Help" menu.

b.    Assure that the proper commands and options are in each menu.

c.     Assure that all buttons on all tool bars have a corresponding key command.

d.    Assure that each menu command has an alternative (hot-key) key sequence which will invoke it where appropriate.

e.     In drop down list boxes, ensure that the names are not abbreviations / cut short

f.     In drop down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hot key combinations.

g.    Ensure that duplicate hot keys do not exist on each screen

h.     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"

i.      Assure that the cancel button functions the same as the escape key.

j.      Assure that the Cancel button operates as a Close button when changes have been made that cannot be undone.

k.     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.

l.      When a command button is used sometimes and not at other times, assures that it is greyed out when it should not be used.

m.   Assure that OK and Cancel buttons are grouped separately from other command buttons.

n.     Assure that command button names are not abbreviations.

o.    Assure that all field labels/names are not technical labels, but rather are names meaningful to system users.

p.    Assure that command buttons are all of similar size and shape, and same font & font size.

q.    Assure that each command button can be accessed via a hot key combination.

r.      Assure that command buttons in the same window/dialog box do not have duplicate hot keys.

s.     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

t.      Assure that focus is set to an object/button which makes
sense according to the function of the window/dialog box .

u.     Assure that all option buttons (and radio buttons) names
are not abbreviations.

v.     Assure that option button names are not technical labels,
but rather are names meaningful to system users.

w.    If hot keys are used to access option buttons, assure that duplicate hot keys do not exist in the same window/dialog box.

x.     Assure that option box names are not abbreviations.

y.     Assure that option boxes, option buttons, and command
buttons are logically grouped together in clearly demarcated areas "Group Box"

z.     Assure that the Tab key sequence which traverses the
screens does so in a logical way.

aa.  Assure consistency of mouse actions across windows.

bb.  Assure that the colour red is not used to highlight active objects (many individuals are red-green colour blind).

cc.  Assure that the user will have control of the desktop with
respect to general colour and highlighting (the application should not
dictate the desktop background characteristics).

dd.  Assure that the screen/window does not have a cluttered appearance

ee.  Ctrl + F6 opens next tab within tabbed window

ff.    Shift + Ctrl + F6 opens previous tab within tabbed window

gg.  Tabbing will open next tab within tabbed window if on last field of current tab

hh.  Tabbing will go onto the 'Continue' button if on last field of last tab within tabbed window.

ii.     Tabbing will go onto the next editable field in the window

jj.     Banner style & size & display exact same as existing windows

kk.  If 8 or less options in a list box, display all options on
open of list box - should be no need to scroll

ll.     Alt+F4 should close the tabbed window and return to previous screen

Specific Field Tests

Field specific tests should be executed where appropriate. These tests will be specific to the data that field is hosting. There are well known test cases for fields like date, time, numeric field etc. It should be the responsibility of QE team at <XYZ ORGANISATION> to ensure that all the field specific test cases have been executed. This section is also categorized in following sub sections-

1. Date Field Checks

a.     Assure that leap years are validated correctly & do not cause errors/miscalculations

b.    Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations

c.     Assure that month code 00 and 13 are reported as errors

d.    Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations

e.     Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations

f.     Assure that Feb. 30 is reported as an error

g.    Assure that century change is validated correctly & does not cause errors/ miscalculations

h.     Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations

2. Numeric Fields

a.     Assure that lowest and highest values are handled correctly

b.    Assure that invalid values are logged and reported

c.     Assure that valid values are handles by the correct procedure

d.    Assure that numeric fields with a blank in position 1 are processed or reported as an error

e.     Assure that fields with a blank in the last position are processed or reported as an error an error

f.     Assure that both + and - values are correctly processed

g.    Assure that division by zero does not occur

h.     Include value zero in all calculations

i.      Include at least one in-range value

j.      Include maximum and minimum range values

k.     Include out of range values above the maximum and below the minimum

l.      Assure that upper and lower values in ranges are handled correctly

3. Alpha Field

a.     Use blank and non-blank data

b.    Include lowest and highest values

c.     Include invalid characters & symbols

d.    Include valid characters

e.     Include data items with first position blank

f.     Include data items with last position blank