Testing WEB Forms

TESTING WEB FORMS

* Start with Happy Path testing first. No other tests until we make sure that an instance of a completed form passes

1. Required Fields
– Each required field has an asterisk
– Error message provided if required field has no input

2. Data Retained in Database – test for each field

3. Emails retaining data (if applicable)
– sent to correct email address
– correct data sent out for each field

4. Values in lists
– one value represents the entire list – one test case per list is enough
– values to be consistent with the rest of the list
– values offered in the list to be complete (compare with similar services)
– make sure “Other”/”None”/”Less than”/”Over” is present when applicable

5. Default Button Assignment
– make sure there is one if it makes sense at all
– make sure the choice of default button is not conflicting with anything
– the choice should be consistent from form to form in the application if it has multiple forms

6. Controls
– identical controls in different forms are consistent (look, name, behavior)
– Check boxes/radio buttons – have reasonable initial values if applicable

7. Edit boxes/Text fields
– Capacity Testing (up to 5 test cases)
– Valid/Invalid Input (3+ test cases)
– ZIP CODE (digits only, 5-digits only)
– Phone Number: No letters, No special Characters
– E-Mail (accepts letters, digits, some special characters – @ . – _ )
– DATE field needs validation for month (01-12), day (01-31), year (1900 – current)
– TIME needs validation for minutes (00-59), hours (00-23), seconds (00-59)

8. Data Input Rules
– Use Lists whenever possible versus text boxes (for example Date of birth)
– Calculate rather than ask for input (for example: calculate county by ZIP)

9. Error/warning messages
– confusing
– misleading