Validating Forms at Client Side

Catching or preventing errors at client side improve the performance of the application, firstly by providing the quick feedback to users and secondly by reducing the load on server by eliminating unnecessary requests.  The application should be developed by taking this into the consideration.  It doesn’t mean that the validation for input should happen only at client side, the server code should be able to handle incorrect input data as well.  Usually at client side, message shown to end user should be more meaningful whereas server should not behave incorrectly or crash due to negative set of input data.

While designing the form of an application, it should be first considered to provide input controls that are smart enough to restrict users to submit only required or correct data, e.g. Calendar control, Combo Box etc.  Secondly, it can have few business rules validation logic at client end also if possible, e.g. Age and Insurance premium requirement validation.

Validating a single form having multiple input controls can be mind boggling if it needs to be tested with extensive permutation / combination as controls can have dependency on each others and correct data from multiple controls together can result a negative data for the application.  For example, consider a simple form with three text boxes representing a date (dd/mm/yyyy), where ‘dd’ as 29, ‘mm’ as 2 and ‘yyyy’ as 2009 is valid data individually but combining it together it represents date as 29^th Feb 2009, which is incorrect as 2009 is not a leap year.

In this article, I will discuss strategy on developing / writing robust test cases for a form, which can be used for validating a form at client side. Usually testers make mistake while writing test cases for these validation, instead of test cases they list numerous test data for validating the form.  The strategy discussed here, is taking cue of a form where input is required manually from end user but the same strategy can be used while reading set of input from some files / database.

Let’s consider a simple form for booking air tickets for roundtrip.  To make it little complex for understanding this exercise, Date and #Tickets information are being gathered from text boxes.  Following are the requirements for each field that are being used for gathering the inputs from users:

1. From (Departure Location)
1. It allows location to be selected from list box
2. To (Arrival Location)
1. It allows location to be selected from list box
3. Depart Date:
1. It takes input for days, months and years separately.
2. The input is taken in text box
3. The Departure date cannot be beyond 60 days in future
4. The format for the day, month and year is DD, MM, YYYY
4. Return Date:
1. It takes input for days, months and years separately.
2. The input is taken in text box
3. The Return date cannot be more than 60 days from Departure date
4. The format for the day, month and year is DD, MM, YYYY
5. Number of Tickets
1. The input is taken in text box
2. The maximum number of tickets that can be booked at a time would be 25

Step 1:  Identification of individual fields

Usually in a form all fields that require input can be considered as individual fields but in few cases (e.g. check boxes, radio box etc.) collection need be segregated logically in a group and test cases are written for the groups. In case inputs are being taken from some file or database, each column represents a different field.

All atomic fields that will be required during filling the above forms are as follows:

1. Location_From
2. Location_To
3. DepartDate_Day
4. DepartDate_Month
5. DepartDate_Year
6. ReturnDate_Day
7. ReturnDate_Month
8. ReturnDate_Year
9. Num_Tickets 

Step 2:  List the fields in (dependency) order

In any form, few fields will be dependent on other fields directly or indirectly or it will be independent in itself.  The task in this step is to segregate the dependent fields together.  It is one of the important tasks for generating correct and relevant test cases using the mentioned strategy.  You can find if two fields are dependent if combination of positive values of two fields results a negative value for the application.

In this example –

1. DepartDate_Day is dependent on DepartDate_Month and combination of two is dependent on DepartDate_Year
2. DepartDate is dependent on CurrentDate as depart date can’t be more than 60 days in advance.  CurrentDate is an implicit field and is calculated.
3. ReturnDate_Day is dependent on ReturnDate_Month and combination of two is dependent on ReturnDate_Year
4. ReturnDate is dependent on DepartDate as return date cannot be more than 60 days from depart date.
5. Location_From is dependent on Location_To as both can’t be same.
6. Num_Tickets is an independent field. 

So, the fields order could be represented as below:

1. DepartDate_Day
2. DepartDate_Month
3. DepartDate_Year
4. ReturnDate_Day
5. ReturnDate_Month
6. ReturnDate_Year
7. Location_From
8. Location_To
9. Num_Tickets 

Step 3:  Create worksheets for positive and negative test cases

Create worksheets, one for positive test cases and another one for negative test cases.

In worksheet containing positive test cases, draw the dependency blocks as well as discussed in step 2.  Please refer below links mentioned in Step 6 and Step 9 for more details related to dependency block and header setting for Negative test cases.

Step 4:  Identify positive test data for individual fields, resulting success on submit of form

While validating negative test cases, it is important to have targeted field value to be negative and others to have positive data.  For the same reason, it is important to identify a positive set of test data that will result success on submit of the form.


Once a set of positive data is ready, list those (as headers) in worksheet containing negative test cases.  It will be referred later while adding negative test cases.

Following is the example of one set of positive data, that should result success on submit of the form and can be used while developing negative test case.  Let’s assume the current date is November 29, 2011.

Field	Value	Field	Value
Location_From	Hyderabad	Location_To	Delhi
DepartDate_Day	05	ReturnDate_Day	20
DepartDate_Month	12	ReturnDate_Month	12
DepartDate_Year	2011	ReturnDate_Year	2011
Num_Tickets	5

Step 5:  Write test cases for individual fields

• Write individual test cases for every field in the ‘Positive’ worksheet. For every test case define the type (negative / positive) and color code if required for the differentiation.  The test case should be self explanatory.
• While documenting test cases for individual fields, think on following lines and try to cover all –

a.      Realistic positive values

b.      Unusual Values  (Positive, though occurs rarely)

c.       Format related  (Negative due to incorrect input format e.g. instead of dd/mm/yyy try mm/dd/yy)

d.      Boundary Cases

e.      Test case should represent a set of test data and not a single test data e.g. {Realistic location with extended ASCII character} rather than Salé (Morocco)

f.       Test cases /test data can be validated at client side itself.  It shouldn’t include those test cases, where the validation can happen only at server end e.g. login authentication failure due to wrong password.

Please refer below link (specified in step 6) to view sample test cases for the individual fields discussed in this article.  Green color indicates positive (normal) test cases, Bright Green color indicates positive (boundary / unique) test cases and Red Color indicates negative test cases and Lime Color indicates the test case can be ignored as either it is duplicate or does not add much value to the testing.

Step 6:  Separate out negative test cases from the positive set of individual field

• Pick only negative test cases from every individual field one by one and append it with negative set.
• For other remaining fields, fill values as identified during Step 4.
• While appending the test cases in the negative list, description should be updated in parallel so that details don’t get lost later.
• Delete all negative test cases /set from the positive test cases work sheet

Note:  Each row in “Negative Test Cases” represents an erroneous condition related to field and should / can be handled at client end itself, either by restricting end user to enter erroneous values or by forcing user to resubmit the form once again after refilling it properly.

Sample Test Cases Resulting After Step 6 & Step 7

Step 7:  Write test cases for all dependent fields considering two at a time

1. Pick (normal) positive test cases from two dependent fields and list all of their permutations separately.
2. Identify the type of test cases after the merger / combination of two fields and update the title / description simultaneously.
3. Add a test case (positive or negative), if something new comes during the process and defines the type and add the description
4. Pick (unique / boundary) positive test cases from two dependent fields and list all of their permutations separately.
5. Identify the type of test cases after the merger / combination of two fields and update the title / description simultaneously.
6. Add a test case (positive or negative), if something new comes during the process and defines the types and add the description
7. Remove duplicates or similar if there are any
8. Remove negative test cases from the positive set and append it to negative test cases list; description should be updated in parallel so that details don’t get lost later.
9. Repeat the step 7a – step 7h for all other dependent fields if there are any.

Notes:

• (Normal) positive test cases and (Boundary / Unique) positive test cases are considered separately to reduce number of test cases.
• In case (Boundary / Unique) positive test cases don’t exist for a dependent field then (normal) positive test case can be used instead for creating test cases.
• In case (Boundary / Unique) positive test cases don’t make any sense with each other, then they should be merged with positive (normal) test cases instead to complete the coverage.
• Few new test cases could arise while combining and would not have thought during listing test cases for individual fields.  For example, any valid location value for ‘From’ and ‘To’ location is a positive test case individually whereas ‘From’ and ‘To’ having the same value results as a negative test case.
• The goal of this step is to come up with least number of relevant test cases and for the same, duplicate test cases or somewhat similar / not relevant test cases should be eliminated on every step whenever possible.

Sample Test Cases for Dependent Field – DepartDate_MonthDay

Sample Test Cases for Dependent Field – ReturnDate_MonthDay

Sample Test Cases for Dependent Field – Location

Sample Test Cases for Dependent Field – DepartDate

Sample Test Cases for Dependent Field – ReturnDate

Sample Test Cases for Dependent Field – DepartReturnDate

Step 8:  Merge positive (normal) test cases from all independent fields

1. Identify independent field having maximum number of positive (normal) test cases
2. Pick all positive (normal) test cases from other independent field and stack with test cases of first independent field identified above.  If numbers of test cases from other independent field are less then stack with remaining test cases of first independent field repeatedly.  Update the title / description of the test cases simultaneously.
3. Repeat the step b for all other independent fields if there are any.

Sample Positive (Normal) Test Cases after Merging from All Independent Fields

Step 9:  Merge positive (Boundary / Unique) test cases from all independent fields

1. Identify independent field having maximum number of positive (boundary / unique) test cases
2. Pick all positive (boundary / unique) test cases from other independent field and stack with test cases of first independent field identified above.  If numbers of test cases from other independent field are less then stack with remaining test cases of first independent field repeatedly.
3. Repeat the step b for all other independent fields if there are any.

Notes:

• In case there are no positive (boundary / unique) test cases exist for other independent field then replace it with positive (normal) test cases of the same field.  The same logic would be valid during execution as well if boundary case related data is not a valid one for a test case.
• All positive (boundary / unique) test cases are targeted together to minimize the number of test cases but at the same time increasing the coverage.

Sample Positive (Boundary / Unique) Test Cases after Merging from All Independent Fields

Sample Negative Test Cases at the End

Step 10:  Merge all positive (normal), positive (Boundary / Unique) and negative test cases in one sheet.

Sample Test Cases for Reservation Booking Form