To test
any Windows based application following points are to be considered:
- It is
essential to have GUI consistency within the Application.
- Should
be alike in look and feel as per any other standard Window software.
- Should
have standard set of keys implemented for the software.
- Should
have clean and neat exit.
While
testing any Windows based application the testing can be broadly categorized
into following compartments. They are:
-
Standardization Testing.
- GUI
Testing.
-
Validation Testing.
-
Functionality Testing.
Standardization
Testing
This
compartment mainly emphasizes on the standardization part of the application.
Standardization means that the application being developed should have standard
look and feel like any other window application. The general guidelines are as
follows:
1. The
application should have first "About Application" screen displayed.
2. Most
of the screens/ dialog box (as on context) should have Minimize, Restore and
Close clicks.
3. Proper
icon should be attributed to the application
4. All
screens/ dialog box should have a proper caption as per the context used.
5. The
application should be seen in the Windows Task Bar as well as status bar.
GUI
Testing
This
compartment mainly emphasizes on the GUI - Graphics User Interface aspect of
the Application. It is not concrete that once GUI guidelines are set that can
be followed blindly. GUI standards may vary from company to company and also
from application to application. But still one can set general guidelines to
have an overall idea on how to start GUI testing. These guidelines apply for
every screen/ dialog box of the application. General guidelines are:
1. All
the dialog box should have a consistent look through out the Application
system. For e.g.- If the heading within a dialog box is blue then for each
dialog box the heading should be of this color.
2. Every
field on the screen should have an associated Label.
3. Every
screen should have an equivalent OK and cancel button.
4. The
color combination used should be appealing.
5. Every
field in the dialog box should have a Short Cut Key support. For e.g.- User
Name
6. Tab
order should be normally set horizontally for the fields. In some case as per
the case the Tab Order can be set vertically.
7.
Mandatory fields should have * (RED ASTERIK) marked to indicate that they are
mandatory fields.
8.
Default key <Enter> should be set as OK for the dialog box.
9.
Default key <Esc> should be set as Cancel for the dialog box.
Validation
Testing
This
compartment mainly emphasizes on the Validation aspect of the Application.
Validation testing mainly depends on the fields set in the dialog box and the
functions it has to perform. But still there are certain common rules that can
be applied. General guidelines are:
1. For
text box fields where value entered has to be numeric check following:
¨ It
should accept numbers only and not alphabets.
¨ If
field usage is such that for e.g., To accept
Total
number of days
Telephone
number
Zip code
etc.
then it
should not accept 0 and negative values.
2. For
text box fields where value entered has to be alpha-numeric check following:
¨ It
should accept alphabets and numbers only.
¨ If
field usage is such that for e.g., accepting
First
Name
Middle
Name
Last Name
City
Country
etc.
then
field value should start with an alphabet only.
¨
Depending on the condition this fields may accept special characters like -, _,
. etc.
3. If the
field is a combo box then it has to be checked for following points:
¨ Check
the combo box has drop down values in it, it is not empty.
¨ Drop
down values should be alphabetically sorted. This might change as per
requirement but as standard practices it should be alphabetically sorted. For
e.g. to select data type from the list it will be as follows:
Date
Integer
String
Text,
etc.
¨
Selection of any drop down value is displayed on closing and opening the same
dialog box.
¨ By
default some value like "Select Value" or "_______" string
is displayed. This is because User comes to know that value is to be selected
for this field. Avoid displaying the first default value in the list.
4. If the
field is a list box then it has to be checked for following points:
¨ Check
the list box has values in it, it is not empty.
¨ List
box values should be alphabetically sorted and displayed. This might change as
per requirement but as standard practices it should be alphabetically sorted.
¨
Selection of any list box value should put a check before the value and should
display the correct value(s) selected on closing and opening of the same dialog
box.
¨ If the
list box supports multiple selection then check whether multiple values can be
selected.
5. If the
field is a list of radio button then it has to be checked for following points:
¨ Check
whether as per requirements all the values are listed. For e.g. to select date
format. Possible values displayed will be as follows:
mm/dd/yyyy
dd/mm/yyyy
mm/dd/yy
dd/mm/yy
yyyy/mm/dd
etc.
¨ Same
selected value should be displayed on closing and opening of the same dialog
box.
6. Data
Controls are to be tested as part of functionality testing.
Functionality
Testing
This
compartment mainly emphasizes on the Functionality aspect of the Application.
The first step to test the Functionality aspect of the Application is to check
whether all the requirements are covered in the software. The actual
functionality testing totally depends from software to software. Still one can
frame general guidelines. General guidelines are:
1. Check
the functionality is covered as per Requirement specifications or Functional
specifications developed for the software.
2. Within
a dialog box identify the dependent fields. Depending on the dependency check
the enabling and disabling of the fields. For e.g.: to create Contact addresses
in any application. To create contact addresses user should be able to add,
delete and modify the information. Contact Addresses will contain information
like, First Name, Last Name, Address1, Address2, City, State, Country, Zip,
Phone, etc., any other information may also be added.
This form
will have the required fields and in addition to that will have Add, Delete and
Update buttons. The functionality of the buttons is as follows:
¨
Initially only Add button will be enabled. Delete, Update buttons will be
disabled. This is because initially there is no data available and unless one
adds one cannot delete or update. In short, unless there is a single valid
record available it is not possible to update or delete.
¨ Only on
selecting a record from the list Delete and Update buttons are enabled and Add
button is disabled. By default No records will be selected.
¨ Delete
and Update should always give confirmation message before actually performing
the operation.
¨ Delete
operation should not show the deleted item in the list.
