Form Based Testing Latest

8/3/2019 Form Based Testing Latest

http://slidepdf.com/reader/full/form-based-testing-latest 1/6

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 byeliminating unnecessary requests. The application should be developed by taking this into theconsideration. 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 behaveincorrectly or crash due to negative set of input data.

While designing the form of an application, it should be first considered to provide inputcontrols 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 atclient 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 eachothers and correct data from multiple controls together can result a negative data for theapplication. 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 butcombining it together it represents date as 29th Feb 2009, which is incorrect as 2009 is not aleap year.

In this article, I will discuss strategy on developing / writing robust test cases for a form, whichcan be used for validating a form at client side. Usually testers make mistake while writing testcases for these validation, instead of test cases they list numerous test data for validating theform. The strategy discussed here, is taking cue of a form where input is required manuallyfrom 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 forunderstanding 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 fromusers:



1. From (Departure Location)

a. It takes string as inputb. The string can have maximum of 30 characters

2. To (Arrival Location)

a. It takes string as inputb. The string can have maximum of 30 characters

3. Depart Date:a. It takes input for days, months and years separately.b. The input is taken in text boxc. The Departure date cannot be beyond 60 days in futured. The format for the day, month and year is DD, MM, YYYY

4. Return Date:

a. It takes input for days, months and years separately.b. The input is taken in text boxc. The Return date cannot be more than 60 days from Departure dated. The format for the day, month and year is DD, MM, YYYY

5. Number of Ticketsa. The input is taken in text box

b. The maximum number of tickets that can be booked at a time would be 25

Step 1: Identification of individual fieldsUsually in a form all fields that require input can be considered as individual fields but in fewcases (e.g. check boxes, radio box etc.) collection need be segregated logically in a group andtest cases are written for the groups. In case inputs are being taken from some file ordatabase, 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_To3. DepartDate_Day4. DepartDate_Month5. DepartDate_Year6. ReturnDate_Day7. ReturnDate_Month8. ReturnDate_Year9. Num_Tickets

Step 2: List the fields in (dependency) orderIn any form, few fields will be dependent on other fields directly or indirectly or it will beindependent 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 mentionedstrategy. You can find if two fields are dependent if combination of positive values of twofields results a negative value for the application.

In this example –

a. DepartDate_Day is dependent on DepartDate_Month and combination of two isdependent on DepartDate_Year

b. DepartDate is dependent on CurrentDate as depart date can’t be more than 60 days inadvance. CurrentDate is an implicit field and is calculated.



c. ReturnDate_Day is dependent on ReturnDate_Month and combination of two isdependent on ReturnDate_Year

d. ReturnDate is dependent on DepartDate as return date cannot be more than 60 daysfrom depart date.

e. Location_From is dependent on Location_To as both can’t be same.f. Num_Tickets is an independent field.

So, the fields order could be represented as below:1. DepartDate_Day2. DepartDate_Month3. DepartDate_Year4. ReturnDate_Day5. ReturnDate_Month6. ReturnDate_Year7. Location_From8. Location_To9. Num_Tickets

Step 3: Create worksheets for positive and negative test casesCreate 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 instep 2. Please refer below links for more details:

Dependency Blocks for Positive Test CasesHeaders for Negative Test Cases Work Sheet

Step 4: Identify positive test data for individual fields, resulting success on submit of formWhile validating negative test cases, it is important to have targeted field value to be negativeand others to have positive data. For the same reason, it is important to identify a positive setof test data that will result success on submit of the form.

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

Field Value Field Value

Location_From Hyderabad Location_To DelhiDepartDate_Day 05 ReturnDate_Day 20

DepartDate_Month 12 ReturnDate_Month 12DepartDate_Year 2011 ReturnDate_Year 2011

Num_Tickets 5

Step 5: Write test cases for individual fieldso 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 thedifferentiation. The test case should be self explanatory.

o While documenting test cases for individual fields, think on following lines and try to

cover all –

a. Realistic positive valuesb. Unusual Values (Positive, though occurs rarely)

https://docs.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AuE_B7aXIFIIdHN5Vy1TM0V0ZUdGRUFhZEZTWkctOEE&single=true&gid=2&range=A1%3AJ5&output=html






c. Format related (Negative due to incorrect input format e.g. instead of dd/mm/yyytry 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. loginauthentication failure due to wrong password.

Please refer below link (specified in step 6) to view sample test cases for the individualfields discussed in this article. Green color indicates positive (normal) test cases,Bright Green color indicates positive (boundary / unique) test cases and Red Colorindicates negative test cases and Lime Color indicates the test case can be ignored aseither 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 fieldand should / can be handled at client end itself, either by restricting end user to entererroneous 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 timea. Pick (normal) positive test cases from two dependent fields and list all of their

permutations separately.

b. Identify the type of test cases after the merger / combination of two fields and updatethe title / description simultaneously.

c. Add a test case (positive or negative), if something new comes during the process anddefines the type and add the description

d. Pick (unique / boundary) positive test cases from two dependent fields and list all oftheir permutations separately.

e. Identify the type of test cases after the merger / combination of two fields and updatethe title / description simultaneously.

f. Add a test case (positive or negative), if something new comes during the process anddefines the types and add the description

g. Remove duplicates or similar if there are any

h. Remove negative test cases from the positive set and append it to negative test caseslist; description should be updated in parallel so that details don’t get lost later.

i. Repeat the step 7a – step 7h for all other dependent fields if there are any.

Notes:

https://docs.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AuE_B7aXIFIIdHN5Vy1TM0V0ZUdGRUFhZEZTWkctOEE&single=true&gid=1&output=html




(Normal) positive test cases and (Boundary / Unique) positive test cases are consideredseparately 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 duringlisting 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 thesame 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 thesame, duplicate test cases or somewhat similar / not relevant test cases should beeliminated on every step whenever possible.

Sample Test Cases for Dependent Field – DepartDate_MonthDaySample Test Cases for Dependent Field – ReturnDate_MonthDaySample Test Cases for Dependent Field – LocationSample Test Cases for Dependent Field – DepartDateSample Test Cases for Dependent Field – ReturnDateSample Test Cases for Dependent Field – DepartReturnDate

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

a. Identify independent field having maximum number of positive (normal) test cases

b. Pick all positive (normal) test cases from other independent field and stack with testcases of first independent field identified above. If numbers of test cases from otherindependent field are less then stack with remaining test cases of first independentfield repeatedly. Update the title / description of the test cases simultaneously.

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

a. Identify independent field having maximum number of positive (boundary / unique)test cases

b. Pick all positive (boundary / unique) test cases from other independent field and stackwith test cases of first independent field identified above. If numbers of test casesfrom other independent field are less then stack with remaining test cases of firstindependent field repeatedly.

c. 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 samelogic would be valid during execution as well if boundary case related data is not avalid one for a test case.

All positive (boundary / unique) test cases are targeted together to minimize thenumber of test cases but at the same time increasing the coverage.

















Sample Positive (Boundary / Unique) Test Cases after Merging from All Independent FieldsSample Negative Test Cases at the End

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

Sample Test Cases for Reservation Booking Form







Documents

Form Based Testing Latest