Checklist for UI Testing
Updated: Jan 19, 2022
APP General tests
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 is 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?
Are 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 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 aligned correctly?
Spellcheck tests are basic...
APP Validation fields
If the validation process is 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 proper message should be presented and describe the current state.
What should happen if a user inserts a valid value and completes the validation successfully?
If the user fails to add an appropriate value in one of the fields and presses “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 specify that the authentication supports Special characters?
All mandatory fields must contain values; if the user failed to insert valid values, the validation process would raise a notification that explains the error that allows the user to supply the missing negative testing for such fields is crucial, validation must fail if the user inserts invalid values (In the worst-case scenario user can insert is shouldn’t use 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 whether the validation is performed on the client-side or the server-side when testing web validation screens.
In any case of a failed validation, the user should receive 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 use an additional password checker to ensure that the user inserts a valid password and save the actual validation time (Enter Password + Re-Enter password).
Different “Injection” tests are crucial for the validation screen; you need to check that your validation screen is protected.
If the user presses the “Cancel” button, the form should be closed, and the validation should not occur.
In a password field, it's a good idea to use a “Password Strength” checker to notify the user that his current password is not secure enough (Mostly used on WEB authentications when creating the first registration).
Do we make the validation against any Database? If so, you must check if the DB columns allow “Null” values.
APP Radio Buttons
Validate 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 using the mouse and keyboard (Arrow keys should allow the navigation between the controls).
When using this object, we need more than one available option for selecting. Therefore, in any given state, only one option should be chosen.
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 primary 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 element's text is written with the requested Size, Color, and Font.
Validate that the button is “Grayed” out when needed and cannot be selected.
Continuing the previous bullet, the “Space” key should do the same.
Validate that the event is not triggered twice when the user presses the button numerous times (Most of the time, the activated function 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 that when the button is pressed, it triggers 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 sorting-based operations options.
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: the 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 don’t need to be 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, Color Etc.
APP Text Boxes
The primary 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.
The “Save” button should be grayed out in most cases 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
Depending 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 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 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 reflects 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 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 “Local” and “Distributed” locations.
Validate that the imported data is reflected in the application as the user intends.
There should be a button for the “Upload” and “Cancel” operations.
Validate that you cannot upload more than one file (multiple Selection).
Please validate that users cannot upload files created in one format, but now the user changes their extension to the one 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.
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 reason to allow file import from unsupported file formats.
APP Date and Time fields
Ensure 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 integrated with varying zones of time 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 ensure that negative values will not raise any error and appropriate notification is displayed to the user.