TESTING WEB FORMS * Start with positive testing first. No negative test cases until we make sure that positive use case (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) - correct address - correct data for each field 4. Values in lists - one value represents the entire list - try just one - to be consistent - to be complete (compare with similar services). - make sure "Other"/"None"/"Less than"/"Over" is present when applicable - negative test case - assign nothing - get the error message 5. Default Button Assignment - make sure there is one - make sure the choice of default button is not conflicting with anything - the choice should be consistent from form to form in the application 6. Controls - identical controls in different forms are consistent (look, name, behavior) - Checkboxes/radiobuttons - have reasonable initial values 7. Edit/Text Boxes - Capacity Testing (5 test cases) - Valid/Invalid Input (3+ test cases) - ZIP CODE (digits only, 5-digits only) - Phone Number: No letters, No special Characters (possible exceptions: dash, round brackets, dot, space). 10 digits (11 if begins with one). Might have 3 edit boxes per number. - EMail (accepts letters, digits, some special characters - @ . - _ ) - are wild cards accepted? - 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 - Calculate rather than ask for input (for example: calculate county by ZIP) - Functionality/Validation 9. Exception handling - messaging - data loss