You are on page 1of 8

Rev No. 2.

0 Header not to be changed 10-02

Review Summary
ITEM SUBMITTED BY Vivek
REVIEW TEAM
NAME(Indicate head) SIGNATURE
1.
2.
3.
REVIEW COMMENTS

ACCEPTED: as it is ( )

REVISION HISTORY

S. No. Version / Revision Date of release Revised Remarks


no. Sections

TESTING STAGE
System Testing

TYPE OF TESTING
GUI

OBJECTIVE

GUI GUIDELINES Page: 1


Rev No. 2.0 Header not to be changed 10-02

Test User Interface Area


A) UI Testing as per UI Guide Line

GUIDELINES FOR USER INTERFACE TESTING


General Interface Guidelines for an Application
1. The UI should be consistent with the external specifications. Any change in the UI
should reflect in the external specifications. If the definitions in external
specifications are not available, then maintain the consistency with the other standard
applications while testing the UI.
2. Test the software for various monitor resolutions. Check its behaviour for consistency
in all the monitor resolutions above and at 640x480. When the software is not usable
for a given range of monitor resolution, mention it in the external specifications
specifying the detailed reason. The software should ideally be able to detect the
present monitor resolution and flash a warning message if the monitor resolution is
set below than the one specified in the external specifications.
3. When there is a relation between two windows i.e. the operation in one window
affects the operation in other, then check for their behaviour. For e.g., if the
information entered by the user in the second window updates the information in the
first window then it refreshes the first window. An analogy to this is the Apply button
of Desktop Property dialog box of Windows environment.
4. Cursor and pointer shape should be proper. E.g.
• When process that consumes more time is under progress, then the mouse
pointer changes to hourglass pointer.
• When cursor or pointer is over edit box there shape should be "caret"
• When the software is performing a lengthy operation that could be paused or
stopped then 'pointer should be an Hourglass with an arrow.
• Similarly, check for the change in shape of the cursor and pointer according
to the requirement of the operation or instance.
5. Test for all the messages and text displayed for correct spellings and grammar. E.g.
the Sentence should start with Capital letter and should end with full stop. It should
be kept short and easy to understand. In case of interrogatory sentence, it should end
with question mark.
6. The colour set by user for the controls should be compatible with the monochrome
monitor.
7. Termination of application should prompt the user through the confirmation dialog
box.
8. There cannot be two instances of an application. An attempt to initiate a new
application instance should activate the first instance only. Two instances should run
smoothly, if allowed.
9. All application should have splash or start-up screen in the beginning. The splash
screen should consist of application name, copyright information, version name,
company's name etc.
If we change the colour setting from the control panel, the application background
setting should change accordingly.
10. The progress bar should be available for multiple or lengthy process.
11. When hot key is pressed for a disabled control, beep sound should prompt the user.
12. All applications should have proper About Dialog box, containing product name,
version information, copy right, and all other dependencies of the product.

GUI GUIDELINES Page: 2


Rev No. 2.0 Header not to be changed 10-02

Interface Design guidelines for Dialog & Views in an Application.


• The dialog box that generally appears after choosing a particular menu item or
command button. Set the title text to be the name of the associate command or the
name of module for the dialog box.
• For any action resulting in irrecoverable change, the Confirmation Dialog box should
prompt the user, e.g. If the user is performing a delete operation, then before deletion
there should be a dialog box prompting the user for confirmation.
• Default button should be one that is most likely to be selected by the user after
current operation.
• Centralise the location of the dialog box with respect to the maximised main window.
• Make the tab order according to the proceeding action expected by the user.
• In case of modeless dialogs, check for all the possible operation while the dialog is
open. If the dialog is not modal then he should be able to perform any other operation
in the application while if modal then user should have to close that dialog before
closing that dialog.
• If any dialog popup on clicking any menu option or push button, the caption of that
button or menu option should be suffixed with ellipses.
• All Dialogs should be above status bar and below the tool bar for maximised
windows.

Interface Guidelines for Controls in an Application.


• Unify the spacing between the controls throughout the application.
• The width and fonts of the editable controls should match. E.g. if a maximum number
of permitted characters in a text box are four, then the length and font should
accommodate it easily.
• Elements which perform similar functions and which are accordingly judged to
belong to a single group should be placed together and separated by group border
lines or frame.
• Functions with arrow key should work with conventions. E.g. In-group option
buttons, select only one button at a time. In case of list box, support the multiple
selections by the CtrI /Shift+arrow keys.
• When a string does not fit to display fully in the assigned display area, truncated and
suffixed the string by three dots.
• Check the scroll bars. Unnecessary scroll bar should not be there, e.g. when the
length of the item exceeds the length of the respective control only then the scroll bar
should be visible or enable.
• For the edit box, permit only valid input range.
• Check far the unnecessary flickering in the controls during any operation.
• After prompting the user for wrong inputs, focus and display should be correct.
• The focus should return to the control from which it invoked. E.g. If user clicks on a
browse button. Then if we come back after selecting any path from browse dialog,
focus should remain on Browse button.

Interface Guidelines for Message box.


• The message box should be task modal, except in the case the application shuts down,
the message box is system modal.
• The Icons on the message box should reflect the significance or its type. E.g. the icon
could be any one of the critical, informations, and exclamation or question as the case
may be.
• Message should be easy to understand and relate to the action. If user is modifying
any property of the object and he tries to commit the operation without saving the

GUI GUIDELINES Page: 3


Rev No. 2.0 Header not to be changed 10-02

changes then he should be prompt with a proper message that will reveal the action of
modifying.
• Focus at an instance should be on logically correct button. For irrecoverable changes
like deletion of a document or changes in the registry, the default button should be
"No'.
• The command button on the message box should be available according to the
message. E.g. if the user wants to move the Volume block; the message box should
contain `Yes', `No’ and 'Cancel' button. When the user wishes to quit the operation
without committing, he can do so through the 'Cancel’ button.

Interface Guidelines for Application's Main Window’s


• All buttons on the toolbar should have supporting entry in the menu.
• There should be consistency in the toolbar and menu ID's.
• Disable the Menu command and tool buttons that arc not relevant for specific task or
option.
• All toolbar buttons should have tool tips.
• Show and hide operation for all tool bars. Should be able to restore its original
position.
• The menu item should not be bigger then the window, if it is, it should be grouped in
hierarchy.
• For each menu, option there should be proper message on the status bar.
• Application should have proper Icon.
• Associate the proper image regarding the operation during the drag and drop
operation
• Check Alt+ tab key combination switches between the primary windows.
• Reactivation of a window should not affect any pre-existing selection; restore the
selection and focus to the previously active state.
• Closing the primary window of an object closes any dependent secondary windows as
well. E g. if user closes the parent window, then by default close the child window.

Interface Design for Access and Hot Keys.


• Access and hot Keys in the menu item or particular dialog should be unique.
• Define the Standard shortcut keys, e.g. Ctrl+X for Cut, Ctrl+ C for Copy, for such
type of operation.
• As there can be some hidden hot keys, try all the combination of access keys on the
dialog. This case may arise at the time, when there are so many controls in the dialog
and some are invisible at a time. At this time User should check for the activation of
the access keys of those controls.
• Execute the push button by focussing on it and pressing the access key of that button
without pressing Alt key.
Interface guidelines for Help.
• Pressing of F1 key on any control should invoke the help, for that control.
• Context sensitive help should be proper and appropriate.
• Pressing of Shift+ F1 key should change the cursor to a help cursor.

GUIDELINES FOR USER INTERFACE FOR WEB BASED APPLICATION

GUI GUIDELINES Page: 4


Rev No. 2.0 Header not to be changed 10-02

The guidelines to be kept in mind while testing Web based applications. The User Interface is
the showcase to the user for an application. The following are guidelines for an application
and it entirely depends on the Specifications for the project.

The following are common vitals issues important for the UI.
 Consistency of UI across the application
 The position of the cursor must be clearly identifiable i.e. by darkening the item or
any other identification.
 Confirmation should be displayed after every successful operation.
 The items on which user do not have rights must not be displayed.
 Refreshing the window should not change the formatting of the window.
 Title of the windows should be appropriate. The titles should be related to the
functionality

Home Page
 Must have Registration link (if the application supports registration for trial
usage)
 Login link or login page link
 Product demo link
 Security Policy
 Contact us
 About Company/US.
Login Page
 Product Logo
 Forgot password option must be available.
 The validations for password must show only a single error in case of login
failure.
 Password should be displayed in encrypted form.
 For password box – on right click copy option should be disabled.
 Remember login information
 Default cursor should be on the User Name edit box.
Main Screen
 Product Logo
 Must have a logout option.
 Support option must be available with the application so that the user can easily
mail the support team.
 User Name & Cabinet name
 Folder name
 The alignment of icons, links, buttons and other items.
Child Windows
 Option for Cancel or close must be available to close the current operation or
window.
 The window must display Title bar and logo.
 The size of child windows for a particular function must be same.
 If the child window is going to refresh its parent window, the parent window
should also be refreshed.
 If the content of parent window is changed the operation on the child window
should not be affected.
Font
Size
 The font for a particular control should be same through out the application.

GUI GUIDELINES Page: 5


Rev No. 2.0 Header not to be changed 10-02

 The font size for comments should be different and bigger compared to other
text as the user can easily read it.

The following properties of the font to be consistent.


 Style
 Type
 Colors

Comments or remarks
The comments should be brief, as user would ignore long text out of laziness.
The labels for all controls must be defined specific.
Controls
Buttons
 Size of the buttons to be consistent
 Color of the buttons and the text to be consistent
 A single approach to be adopted for 2-D /3-D buttons

Font – Consistency to be followed for


 Style
 Size
 Color

Text Edit box


 The size for the text box must be same in the window.
 Minimum and maximum size must be fixed for the application
 Input of value must not be allowed beyond boundary value.

Multi Line Text box


 The maximum character limit must be displayed with the box.

Check box
 Disable: The option must be disabled for operations not allowed.

Radio buttons.

Combo box
 A minimum size of the box must be defined if no item is available in the list.
 The size of the list box can depend on the length of the item since restricting
size can confuse the user if in case two items with same name exists.
 In case of batches being implemented the next and previous option must be
available.
 Sub folders
 In case of a return key the item should be selected.
 Lower list box should open in upper direction.
Action
Mouse Clicks
 Single click to open the link
 Multiple clicks should not be supported on any operation.

Return key
 Return key action must be enabled in each window.

GUI GUIDELINES Page: 6


Rev No. 2.0 Header not to be changed 10-02

 The return key should perform the same operation as with OK button of the
screen.
Tab Order

Links
Color: different for used links.
Underlined
Font

Errors and warnings


Confirmation for all failures with recovery of UI being input must be available.

Error messages
 Front End errors should be clearly identified
 Server Error messages to be identified. These messages should not name any
module used in architecture of the application. These message would be
preferred if any error number is displayed.

Warnings messages
 Any deletion operation should be performed after a warning message to the
user.
 For any warning for invalid data or operation, recovery of data should be
possible, so that the user don’t need to input complete data again. Further it is
also advisable to return the focus to the particular field in which incorrect
value has been entered.
Dialogs
 The error or warning message dialogs must be clearly identified.
 The validation dialog box must display correct messages (grammatically and
content)
 The icon for type of messages must be displayed if possible for WARNING
or ERROR.
 Any dialog for download etc. to be invoked once.
 The file name to be displayed in document download should be correct.
Cursors
 The tool tips to be displayed must be clearly identifiable for
document/folder/objects.
 Cursor Bringing focus to an item must the style of the icon.
 The cursor should change if the application is busy.
Selection
Multi Selection
 For multi selection check box should be marked if all the options are selected
 Enabling & disabling for the operations, which can be performed.
 Select all and deselect all buttons must be available for multiple selections.

Selection
 Clicking on a link should select the folder and display it contents in the
middle frame.
 Clicking on document link the document should be selected.
Batches
 The option for next or previous batch must be disabled if no more items exist.
Help
 Online help to be available in every window

GUI GUIDELINES Page: 7


Rev No. 2.0 Header not to be changed 10-02

Mails
 The mails for the application if consist logo in the mail.
 It is also advisable to display the URL in the mail.

ENCLOSED:

$\iWDM 2004 Docs\QA Documents\GUI Guide Line\*.Doc

GUI GUIDELINES Page: 8