Saturday, September 5, 2015

User interface testing – The ultimate checklist


General 
 
  • Every software that supports the “Help” functionality should be triggered from the “F1” button.
  • It’s basic to try to start the application few times while another instance in “loading” process.
  • Make sure that one form buttons doesn’t affect sub-form when it’s not needed or specify.
  • A relevant notification to the user that the current state of the program is “Processing”.
  • In any case that the changes made by the user are final, make sure that the “Cancel” button reacts as “Close” button.
  • In most cases you should have the ability to perform every operation from the Key board and without the mouse.
  • Web applications should be tested with different resolutions (600*800, 1920*1080…).
  • Try to start new instance of the software while the first instance already in active state.
  • Is there a default object that highlighted when the user starts the application?
  • The “Help” menu should be available in the main screen navigation bar.
  • The application name should be displayed on the application main form.
  • In most cases GUI forms should have the Minimize/Maximize options.
  • Try to run the application from different locations (Client<->Server).
  • Each application should described with the version number.
  • Text should be justified (otherwise it’s not relevant).
  • In most cases the application integrated with a dedicated Database (Sql, Oracle…), in many situations the application DB requires a value from the user (the expected Value cannot be empty) therefore those fields will be marked with default values (GUI) and if not specified differently by the user those default values are going to be the one that will be used by default.
  • Closing the application shouldn’t occur without an approval notification that allows the user to “Approve” (OK) or “Decline” (Cancel) is operation.
  • In any case that cause the application to move into “Loading” state it should display a
  • TAB functionality should be available with the order of left to right (TAB – Moving forward / SHIFT + TAB is moving backwards).
  • The main functionalities of the application should have a corresponding “Shortcut” key that user can trigger from his Keyboard.
  • In any case of “Disabled” field the user cannot use the functionality, in addition “Focus” on that field shouldn’t be available.
  • Applications should start based on few triggers:

  • Double click on the application icon.
  • Double click on the application shortcut.
  • Right Click on the application icon -> Select the application
  • Command line (With a dedicated syntax).
  • Script file (With a dedicated syntax).

Color:
Color tests are relevant for all forms, the following list contains the main questions you should ask yourself when testing the GUI from this side:

 
  • Do the form objects (Drop-Down list, Radio button) displayed with the correct color?
  • If form or field state is set as “Read-Only”, do we grayed them out?
  • Are the “Warning” notifications displayed with the relevant color?
  • If fields become “Grayed-Out”, do we display the correct color?
  • In general, are the application colors are usable by the client? 
  • When a field in focus, do we mark it with different color?
  • Do the text inserted in text fields are in the correct color?
  • Form title and description displayed in the correct color?
  • Are the Hyperlink colors are in the expected color?
  • Loading screen displayed with the correct color?
  • Form background color is the correct one?
  • Loading process bar in the correct color?
  • Is the sub-screens in the correct color?
  • Are the buttons are in the right color?

Syntax:
Every application contains different aspects of syntax, the following list is relevant when testing a software from this side: 
  • Are all the screen texts in the text box are aligned correctly?  
  • Does the second word should start with Upper/Lower case?
  • Is the text in all objects are written with the correct font?
  • Is the screen text being written with the correct font?
  • Is the screen text being written with the correct size?
  • Is the first char (If relevant) in a word set as capital?
  • Are all the screen texts are aligned correctly?
  • Spellcheck tests are basic...

 Checklists and Guidelines for a specific Web Element:

Validation fields
  • If the validation process limited to a MAX number of failures, the user should receive a valid notification that explains the remaining number of authentication attempts, if the user failed to authenticate within the limited attempts a valid notification should be presented and explain the current state.
  • What should be happening if user insert a valid values and the validation completed successfully?
  • If the user failed to add an appropriate value in one of the fields and press “Ok” in most cases he cannot edit the field (That cleared from the inserted value) and should re-enter a new value.
  • Does the SRS doc, specified that the authentication support Special characters? 
  • Does the SRS doc, specified that the authentication support negative values? 
  • All mandatory fields must contain values, if the user failed to insert valid values the validation process will raise a notification that explains the error that allows the user to supply the missing value.
  • Negative testing for such fields are crucial, validation must be failed if user insert invalid values (In the worst case scenario user can insert invalid values and the validation pass).
  • Check if the validation fields should support a specific format of values.
  • Do the validation fields are “Case Sensitive”? 
  • If a mandatory field remains empty and the user presses the “Ok” button, the application should mark the empty field to direct the user to his fault. 
  • You must understand if the validation performed on the client side or on the server side, it’s really manner when testing web validation screens.
  •  In any case of invalid validation, the user should notify that the validation process failed with an appropriate notification.  
  • If the form contains mandatory fields it’s usually marked with asterisk (*), but that’s not all, most users will not understand the meaning of such mark. Therefore, you should add a note that explains the values that the user should enter.
  • In most cases the validation fields should be limited with MAX and MIN values (Boundary tests are classic for such fields). 
  • It’s highly recommended that the authentication object will use an additional password checker to make sure that the user insert a valid password and save the actual validation time (Enter Password + Re-Enter password). 
  • Different “Injection” tests are really important for validation screen, you need to check that your validation screen is protected. 
  • In any case that the user press the “Cancel” button the form should be closed and the validation should not take place.
  • In a password field, it’s a good idea to use a “Password Strength” checker, to notify the user that is current password is not secure enough (Mostly used on WEB authentications when creating the first registration). 
  • Do we make the validation against any kind of Database? If so, you must check if the DB columns allow “Null” values. 

Radio Buttons
  • Validate that there is a “Tab” sequence that allow the user to navigate between all the available radio buttons. 
  • Validate that the relevant event is triggered when the user change the default selection.
  • Validate that all radio buttons are configured and displayed with the expected alignment.
  • Validate that the application is displayed with the accurate “Default” value.
  • Validate that the user cannot “Edit” the available radio buttons.
  • Validate that there is a valid label for each button.
  • By default at least one button should be selected. 
  • Every button should be available for selection both by using the mouse and keyboard (Arrow keys should allow the navigation between the buttons).
  • When using this object we need more than one available option for selecting. Therefore, in any given state only one option should be selected. 

Hyper Link
  • Validate that the Hyperlink is triggered from the Keyboard (Ctrl+Mouse Click).
  • Validate that the Hyperlink is triggered from the Keyboard (Ctrl+Enter).
  • Validate that the Hyperlink is clickable(Single Click / Multiple Clicks)
  • Validate that the Hyperlink is identified with the basic blue color.
  • Validate that the Hyperlink is working with a valid landing page.
  • Validate that the Hyperlink is not editable

Push buttons
  • Validate that the text of the element is written with the requested Size, Color, and Font Etc.
  • Validate that when needed, the button is “Grayed” out and cannot be selected.
  • Continuing the previous bullet, the “Space” key should do the same action.
  • Validate that the event is not triggered twice when the user press the button numerous times (Most of the time the function that triggered is created as “Single instance”).
  • Every button should be triggered by the mouse when the user clicks on it. 
  • Validate that the Element is displayed with the predefined name.
  • Validate the Default value of the button (Enable/Disable property).
  • Validate when the button is pressed, is trigger the necessary event.
  • Make sure that all buttons are similar in size, shape and size.
  • Esc should active the “cancel” button (if available in form).
  • Validate that there is a default button on the screen. 
  • Every button should have the option to triggering with an appropriate keyboard Shortcut (You must make sure that duplicate shortcuts are not existing).

Drop down lists / List Boxes /Combo box
  • The User should have the option to change the values' order using different options of sorting based operations.
  • Drop Down values must be presented with order (usually determined alphabetically).
  • When the user selects a value, this value should be displayed on the main Drop Down field.
  • The “Drop Down list” is an object that doesn’t receive any typing inputs. 
  • Validate that the user cannot edit/Delete/Add the default values. 
  • Validate that the user can navigate while using a specific keyboard char, Example: user select char ‘T’, the first value that starts with this char should be highlighted. 
  • Validate that the user cannot select more than one value.   
  • Select the Drop-Down Arrow, when pressing on it, validate that the element values are displayed/Closed (Based on the current status).
  • Validate that the list is not cleared from values, in any event that triggered from another element of the application.  
  • Drop Down objects doesn’t need to set with default values, if that’s the case, the default value should be a “Blank” field.
  • Validate that the Drop-Down Values/Element label is written with the requested Font, Size, and Color Etc.

Export File Scenarios

  • Depends on the application, sometimes you have a progress bar that indicates the current export time, if that’s the case, make sure that this window is synchronized with the actual export operation. 
  • The user should have the option to export the file both to local and distributed locations.
  • Validate that the user receives a notification for an “unsuccessful” export operation.
  • Validate that the user receives a notification for a “successful” export operation.
  • There should be a button for both the  “Save” and “Cancel” operations.
  • The user should have the option to select the Name of the exported file.
  • There should be an option to export both small and large data files.
  • Validate that the exported data is reflecting the application data.
  • There should be a default file name format.
    Validate that the exported data is readable.
  • Validate that when the file contains “Special Characters” the exported file can display them as they represented in the tested application.
  • Validate that the user has a predefined list of the supported file formats that he can select when exporting the required data(There is no real reason to allow export to a file format that cannot represent the exported data).

Text Boxes
  • The basic test for this object is to overflow the text box by typing the MAX available of characters.
  • The User should have the option to select specific text when using the Shift + Arrow Keys.  
  • Text box must support Copy/Paste of syntax from different locations. 
  • Double click on the text should highlight the entire syntax.
  • Every text box should be tested with special characters.
    Enter syntax in the text box with space at the beginning.
  • Enter syntax in the text box with space at the end.
  • The User has the option to enter text into the box.
  • Try to use Blank fields and sync the value to DB.
  • Text box should be limited to Max characters. 
  • Do we support upper and lower case?
  • Testing for text box must involve negative testing that indicates that the field behave correctly when user insert invalid characters.
  • In most cases the “Save” button should be grayed out if the user not yet insert syntax to the text box field.

Checkbox

  • Validate that a “Grayed” out check box, cannot be selected by the user.
  • Validate that the user can Check/Uncheck values by the mouse “Right” key. 
  • Validate that each checkbox are configured with the relevant label.  
  • Validate that the default values are selected/not selected.
  • Validate that there is a valid / logic Tab sequence order. 
  • Validate that a relevant event is triggered, in any case of the predefined element values. Validate that the user can Check/Uncheck values by the keyboard “Space” key. 
  • Do we support upper and lower case?

Upload File Scenarios
  • Validate that you can Import different file size (Small, Size 0, Max Supported Size, Etc.).
  • Validate that the user receives a notification for a “successful” import operation.
  • Validate that the user receives a notification for an “unsuccessful” Import operation.
  • Validate that you can import files from both “Local” and “Distributed” locations.
  • Validate that the imported data is reflected in the application as the user intend.
  • There should be a button for both the “Upload” and “Cancel” operations.
  • Validate that you cannot upload more than one file (multiple Selection).
  • Validate that you cannot upload files that created as one format, but now the user changes their extension to the one that supported by the system.
  • Validate that you can import files with Special characteristics.
  • Validate that you can import files with different Unicode text.
  • Upload files with spaces in their names.
  • Depends on the application, sometimes you have a progress bar that indicates the current import time, if that’s the case, make sure that this window is synchronized with the actual Import operation.
  • Validate that the user has a predefined list of the supported file formats that he can select when importing the required data (There is no real reason to allow file import from unsupported file formats.
 
Date and Time fields
  •  Make sure that the application can handle any case of “Leap” years (if your application failed to handle such cases an appropriate notification should raise for the user).
  • Can you change the date/time (insert day in the year location, insert year in the month location...) order and approve the change? 
  • Applications must be tested with OS “Time Zone” changes, different components that integrated with different time zones mail lead to massive failures in the data synchronization and integrity (Believe me I know it personally…).
  • Change Time zones in specific components to see how the application can handle different date formats.
  • A Different date fields contain MAX and Min values, you must make sure that negative values will not raise any error(Boundary tests are classic..) and appropriate notification displayed to the user, Examples: 

Value
Day
Month
Min
1
1
Max
31
12
Special 1
Value > two chars
Value > two chars
Special 2
0 or 00
0 or 00

No comments:

Post a Comment

My Presentations