Basic Standard for testing

Testing 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 with basic testing. These guidelines may apply for every application.

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. These are depending on the requirement of the project. 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 should be set as OK for the dialog box.

9. Default key 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:

a) It should accept numbers only and not alphabets.

b) 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:

a) It should accept alphabets and numbers only.

b) 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:

a) Check the combo box has drop down values in it, it is not empty.

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

c) Selection of any drop down value is displayed on closing and opening the same dialog box.

d) 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:

a) Check the list box has values in it, it is not empty.

b) List box values should be alphabetically sorted and displayed. This might change as per requirement but as standard practices it should be alphabetically sorted.

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

d) If the list box supports multiple selections 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:

a) Check whether as per requirements all the values are listed. For example to select a date format. Possible values displayed will be as follows:

MM/DD/YYYY

DD/MM/YYYY

MM/DD/YY

DD/MM/YY

YYYY/MM/DD

b) 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:

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

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

c) Delete and Update should always give confirmation message before actually performing the operation.

d) Delete operation should not show the deleted item in the list.