Common Validations for Web Forms

Forms are the only way through which the user and the website can interact with each other. Unusable forms can have a negative impact on the number of leads and hence the profit that can be generated from a website.

A] Error Messages:

Any error message should communicate the following as best it can:

Where the errors are: An error response should mention for which input field the error is related to. When referring to an input, traditionally use the name of that input field which will be helpful for the user to understand easily.

How an error may be fixed: If the error is simply to let the user know they missed a required field. It’s always best to communicate what the solution might be. For example,  if a telephone number can’t accept alphabetic characters, then tell the user. If a user didn’t enter the date in the correct format, show them an example of what the correct format is.

B] Form must retain previous data entries:

When submitting a form with errors, rather than having to fill out the entire form again, leave the correct data in the form. If the form can’t retain previous data entry, then the users might get frustrated and not fill the form again.

C] Don’t use alert dialog boxes for validation responses:

Here are a few reasons why:

  1. 1. When an alert box is displayed, it must first be closed before returning to the form.
  2. 2. Once closed, the only way to view the error again is to re-submit the form. This gives the user no information to refer back to.
  3. 3. When using alert boxes and pop-up windows, it is common that only the first error found is displayed, rather than a full list of errors. The form is then re-submitted by the user multiple times to discover multiple different errors.

D] Field Validation:

Email Field:

  • Valid email format aa@bb.sg / aa@bb.co.uk (and similar).
  • First character should not be a special character.
  • Special characters allowed are _ . -
  • Alphanumeric characters should be allowed.
  • For email and confirm email id fields – No copy or paste function is allowed.

Name Field:

  • First name should be mandatory.
  • Only accepts alphabets.
  • Lead and trail space should be truncated.
  • Maximum and Minimum length should be tested (Depends on requirement).

Password Field:

  • Typing value should be encrypted.
  • Minimum and Maximum length should be validated (In general Min.6 and Max.12).
  • Copy and Paste functionality should not be allowed for Password and Confirm Password field.
  • For all instance Password field should be followed by Confirm Password field.

Drop down:

  • Default text should be “-Select-” or “-Select item-”
  • Should be enabled always (depends on spec).
  • Menu items should be sorted with respect to the requirement (alphabetical order by default).

Amount/ fees field:

  • Do not allow to use comma (,) and dot (.)

Mobile or Phone Number Field:

  • Alphabets should not be allowed
  • In special characters only hyphen (-) and plus (+) signs are allowed.

Public Forms:

  • Public forms such as registration form, comment form, mail to support form, etc. should have “Captcha” to submit. To overcome Auto-bot registration and spam,  it should be used.

Date of Birth Field:

  • Should mention the format of input (mm/dd/yy or mm/dd/yyyy or dd/mm/yy  etc.)
  • If accepting the value for date, month and year in separate field, only then numerals should be allowed. Otherwise if you use single text box to get data then mention the separator allowed along with the format text. For example: mm/dd/yy or  mm-dd-yyyy

Calendar Range:

  • Should clearly explain the date format (dd/mm/yy or dd/mm/yyyy or mm/dd/yy)
  • End date should not be greater than current date.
This entry was posted in Quality Assurance & Testing and tagged , . Bookmark the permalink.

Leave a Reply