Checklist for UI Testing



APP General tests

  • Every software that supports the “Help” functionality should be triggered by the “F1” button.

  • It’s basic to try to start the application a few times while another instance in the “loading” process.

  • Make sure that one form buttons don’t affect sub-form when it’s not needed or specified.

  • 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 a “Close” button.

  • In most cases, you should have the ability to perform every operation from the Keyboard and without the mouse.

  • Web applications should be tested with different resolutions (600*800, 1920*1080…).

  • Try to start a new instance of the software while the first instance already in an 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's 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 be described with the version number.

  • The 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.

  • TAB functionality should be available with the order of left to right (TAB – Moving forward / SHIFT + TAB is moving backward).

  • The main functionalities of the application should have a corresponding “Shortcut” key that the user can trigger from his Keyboard.

  • In any case of a “Disabled” field, the user cannot use the functionality, also “Focus” on that field shouldn’t be available.

  • Applications should start based on a 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).

  • The script file (With a dedicated syntax).


App Colors

  • 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 a 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?

  • Loading process bar in the correct color?

  • Is the sub-screens in the correct color?

  • Are the buttons are in the right color?

APP Syntax

  • Are all the screen texts in the text box are aligned correctly?

  • Should the second word start with Upper/Lower case?

  • Is the text in all objects are written in 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...

APP 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 happen if a user inserts a valid value 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 supports 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 is crucial, validation must be failed if the user inserts 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 the server-side, its manner when testing web validation screens.

  • In any case of a failed validation, the user should receive an appropriate notification

  • If the form contains mandatory fields it’s usually marked with an asterisk (*), but that’s not all, most users will not understand the meaning of such a 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 to 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 inserts a valid password and save the actual validation time (Enter Password + Re-Enter password).

  • Different “Injection” tests are really important for the validation screen, you need to check that your validation screen is protected.

  • In any case that the user presses 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.

APP Radio Buttons

  • Validate that there is a “Tab” sequence that allows the user to navigate between all the available radio buttons.

  • Validate that the relevant event is triggered when the user changes 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.

APP HyperLinks

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

APP Pushbuttons

  • Validate that the text of the element is written with the requested Size, Color, and Font.

  • 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 presses 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 the form).

  • Validate that there is a default button on the screen.

  • Every button should have the option to trigger an appropriate keyboard Shortcut (You must make sure that duplicate shortcuts are not existing).

APP Dropdown 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 Downfield.

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

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

  • The text box should be limited to Max's characters.

  • Do we support the upper and lower case?

  • Testing for text boxes must involve negative testing that indicates that the field behaves correctly when the user inserts invalid characters.

  • In most cases, the “Save” button should be grayed out if the user does not yet insert syntax to the text box field.

APP Checkboxes

  • 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 is 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 the upper and lower case?

APP 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).

APP Import File Scenarios

  • Validate that you can Import different file sizes (Blank File, 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 intends.

  • 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 are created as one format, but now the user changes their extension to the one that is 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.

APP 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 are 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.

  • Different data fields contain MAX and Min values, you must make sure that negative values will not raise any error and appropriate notification displayed to the user.



406 views0 comments

Recent Posts

See All