Testing - Forms

“No amount of testing can prove a software right, a single test can prove a software wrong.”

Testing forms

Forms are often the hiding place of complicated business logic so we will start off this section with a quick primer on testing forms.

Since the set of inputs a non-trivial form can take is often infinite, it is literally impossible to test everything. This is why you need to be smart about it by using some basic testing techniques and shortcuts.

Equivalence partitioning

Equivalence partitioning is partitioning a set of possible inputs into classes. Each member of the class is deemed identical to all other.

Let's say you have an input field which can only accept numbers in the range of 1-200.000. These would be the equivalence classes you have to check:

Boundary value analysis

We can expand on the aforementioned by including boundary value analysis as well. That means you would also use the following inputs:

Here's an example:

bva.png

We do this because almost everyone had a problem with OBOE in their coding carrer.

Addendum

Additionally, because you are curious, you could also:

Even Google had a problem with the first point: In December 2014, Google said that PSY's music video "Gangnam Style" had exceeded the 32-bit integer limit for YouTube view count, necessitating YouTube to upgrade the counter to a 64-bit integer.

Field validation table

Let's look at some data types and inputs that are considered valid and invalid.

Data Type Valid Inputs Invalid Inputs
Integers or Numbers • Only Numbers
• Less than the limit (N)
• Enter the value within the limit (N + 1)/2
• More than the limit (N + 1)
• Numbers with precision
• Numbers in Exponential Form
• Negative Integers
• Only Alphabets
• Numbers + Alphabets
• Numbers + Special Characters
• Unicode Characters e.g. U+0000, U+0001
String • Only Alphabets
• Only Numbers
• Only Special Characters
• Numbers + Alphabets
• Numbers + Special Characters
• Alphabets + Special Characters
• Less than the limit (N)
• Enter the value within the limit (N + 1)/2
• More than the limit (N + 1)
• Unicode Characters e.g. U+0000, U+0001
Date • Check that whether date picker is present or not
• Check that date field is non editable
• Ensure that, upon right clicking on the date field, paste option should be disabled & copy option should be enabled
• Ensure that, upon clicking on date in the calendar, it should be displayed in the date field
• Select a leap year and verify the days in February month
• Select a non leap year and verify the days in February month
• Ensure that, calendar is having provision to select any year, month (combo box, drop down list, links etc.)
• Ensure that, clear button is present in the date picker to remove the selected date

Forms feat. UX - Capitalization & keyboard types

To round this off, let's relax and talk about UX and capitalization in forms.

You'll rarely find capitalization principles and keyboard type suggestions in your projects' requirements list. That's because these things are very often on the "goes without saying" list, but it's always a good idea to confirm the implementation.

Input field type Capitalization and other rules Input type
Name/surname • Each word should start with the capital letter.
• All letters and symbols are allowed.
text
Email • All letters and symbols are allowed. email
Phone number • Only numbers are allowed. tel
Number • Numbers and symbols are allowed.
• Try to use the "tel" input type as often as you can, because the "number" type is useful only when symbols are allowed. In all other cases, "tel" type is the superior option.
number
Password • All characters are allowed
• All characters are hidden by default.
password
Date • The default date picker component should appear. date

testing-prince-of-versions.gif