Testing Input Elements - Notes and Exercises

Tags:
Categories:

Software Testing related hints and tips for testing input elements.

About input Elements

‘input’ element - input fields are a way of allowing the user to enter information, it is usually used in a form to submit information to the server.

The MDN documentation has a useful section on Client Side Validation which is worth reading.

But that section doesn’t go far enough to describe the various ways that the client side validation can be bypassed and over-relied on.

Important attributes are:

  • type - the type of the input field
    • hidden which prevents display of the field but submits it to the server
    • text a free format single line entry field
    • number creates a GUI control that only allows number entry
  • required - defines if a value in the input field is required
  • name - if an input is part of a form, it will only be submitted to the server when it has a name

input elements are often used within a form. In the example page, all the input elements are in a form. You can see that the “Form Control” input elements control the form to some extent, resetting data, or submitting the form. When a form is submitted, some of the input types provide some validation protection e.g. email, url, etc.

Types

There are many ’types’ of input and some have more nuances than others e.g. ’number’ because it allows non-numeric input characters for scientific notation.

Listed below are different input different types with explanations.

It is important to:

  • recognize that the controls are complex browser provided controls. We do not want to test these controls.

  • understand that at some point we will either use JavaScript to ‘get’ the value, or send the value to the server, we do want to test that our application can handle any ‘value’ generated by the control.

  • mdn docs on different types

Basic Types

Hidden

<input type="hidden" value="bob"/>
  • cssSelector: input[type="hidden"]

Hidden input elements are a common source of issues. They often give too much information away e.g. private details of the user.

There is a global attribute to hide ’things’ from rendering, but the hidden type is different and is especially problematic. A hidden input is not shown on screen but is submitted to the server when a form is submitted.

They sometimes allow escalation of privilege e.g. a hidden field for ‘usertype’ if amended to ‘admin’ might change the user permissions for a request. They sometimes feed information to the server that should be pulled from the database e.g. a hidden field on a ‘add to cart’ or ‘checkout’ form which has the item price, if this is used to calculate the price on the server then it is possible for the user to amend it and get items for free or even a refund (-ve amount as value).

If any ‘hidden’ field is important and used in the processing then it needs validation applied prior to processing. Too many development teams make the assumption that the hidden values can not be changed by the user. But they can.

Testers can amend the values using Dev tools, or by amending the HTTP request through a proxy or in the network tab.

Test Ideas:

  • Amend the value of the attribute, when you now submit the form for processing did it make a difference?
  • What happens if you amend the DOM and add a hidden field with the same name before or after the one in the form? Use different values, which field value is used?
  • If the value is base64 then decode it and see what it tells you.

Button

<input type="button" value="A Button"/>

A button in a form is usually there to trigger some JavaScript to validate, or set values on the form.

The JavaScript might be visible in the on... attribute in the button, or you might have to use the Developer Tools to see the attached Event Listeners.

The value is the text shown on the button.

When the form is submitted, the ‘value’ is not sent through to the server.

It is also possible to have buttons ‘outside’ a form, associated with the form by using a form attribute, there are other associated attributes to control a form like formaction and formmethod.

So… don’t assume that only input buttons in the form are related to the form. Check the full DOM.

Checkbox

<input type="checkbox"/>

A Checkbox is a boolean input. The value of the checkbox is passed to the server, when it is checked.

Radio

<input type="radio" name="choice" value="One"/>
<input type="radio" name="choice" value="Two"/>

When one of the radio buttons is selected, the others are deselected.

Note that when an event on one radio button is triggered, events on other radio buttons are not triggered e.g. there is no ‘unchecked’ event fired.

Also the radio buttons need to have the same name. The value sent through to the server is the value of the selected radio button.

If no radio button is selected, no value is sent through to the server.

Text Input Elements

The following are all plain text controls. The concept that a field might be a “Url” or “Email” suggests that full validation is provided just by adding a type. Fields are only validated when they have a value and additional validation is created by the developer, usually by using the pattern attribute.

The pattern attribute is a regex and needs to be tested. Because it is a Regex it could be automatically checked against a wide range of input data.

Browsers may style the fields differently.

A few gotchas:

  • sometimes the size and maxlength attributes get mixed up, size controls the display width of the input, maxlength the maximum number of characters that can be entered.
  • size
  • maxlength

Take care about autocomplete values to make sure there is no accidental information bleed or chance of misuse or setting the wrong values in a form.

Text

<input type="text"/>
  • cssSelector: 'input[type="text"]'

Text input fields are often a source of issues when used for non-text data. There are many types available e.g. date, time, number, and these specialised types offer some input validation. “text” offers no default input validation, although it should remove new-line characters. This means that if ’text’ is used, the system validation needs to handle any input. There are additional attributes that can help provide client side validation e.g. pattern, required etc.

Test input fields often have javascript events associated like ‘onchange’ so check the event listeners to make sure you test the JavaScript.

Test Ideas:

  • “Should this really be free text? If additional validation is added to check it is a ’number’ or a ‘date’ then there are actual domain types for that.”
  • “Check the associated attributes e.g. required, maxlength are they correct?”
  • “Try a range of invalid characters”
  • “What happens if this is left blank?”

<input type="search"/>

This seems to be basically a text input. I’d expect to see this type used of the UI is offering some sort of ‘search’ capability, even though the type would offer no additional validation. It might be useful as a locator strategy to hook in JavaScript dynamically on to every search field.

Password

<input type="password"/>

Note: just because you “can’t see the input” doesn’t mean the input is ‘safe’, the value can be retrieved by JavaScript. And make sure that any use of “password” is only used on a page served and processed via https.

Notes:

Email

<input type="email"/>

If a value is entered, then the form will perform some basic validation on the email address.

This is going to be syntactical validation i.e. does the email match a basic email format. But server side validation should apply to make sure the email is suitable for the application e.g. you may not want people signing up for paid plans to your application with a mailinator.com address.

Url

<input type="url"/>

If a value is entered, then the form will perform some basic validation on the url.

Tel

<input type="tel"/>

Validation is only performed if a pattern attribute is supplied. But you may well notice difference in the input presented to the user, particularly when this field is used on a mobile device.

Number Controls

Number

<input type="number" value="10"/>

Number is not restricted to positive Integer so it is possible to add characters that the server or follow on functionality is not expecting e.g. “-.e” so we need to try the full range of input characters.

Test Ideas:

  • Number may include characters you don’t expect, try them e.g. “e”, “.”,"-","+"
  • Try changing the type to “text” and submitting a very invalid input.

Range

<input type="range"/>

If no attributes are provided for min and max then the range control defaults to 0 to 100.

The benefit of a range control, compared to a number control, is that a value will always be sent to the server.

Special Format Controls

The special format controls are browser implemented. You do not need to ’test’ the rendered form. e.g. when you choose a colour, you do not need to ’test’ the colour picker dialog.

When we see Special Format Controls, we are interested in making sure that the server can handle the values generated and that any JavaScript code attached to events is processed correctly.

Color

<input type="color"/>

Date

<input type="date"/>

DateTimeLocal

<input type="datetime-local"/>

File

<input type="file"/>

Month

<input type="month"/>

Time

<input type="time"/>

Form Controls

Reset

<input type="reset"/>

When reset is clicked, by default the entire form will reset to the default values.

This is browser implemented functionality so it is worth checking that it actually does what is expected for the context used by the input form. If the default doesn’t do what is anticipated then it might be better to have a button with JavaScript to reset the form.

Image

<input id="image-input" type="image" src="button_image.png"/>

The Image control is interesting because it defaults to acting as an alternate submit button when the user clicks on the image located by the src.

Submit

<input type="submit"/>

The submit button will render as submit, if a value is added then this will be shown as the button name.

By default the submit will submit using the method (e.g. post) and to the action url in the form. If these attributes are not present in the form then the page will refresh.

The default processing can be overridden by JavaScript, and if this is the case it is worth testing the override carefully.

Form Submission

Name

<input id="text-input" type="text" name="text"/>
  • cssSelector: 'input[name="text"]'

input elements in a form will have their values submitted to the server, only if a name attribute is added to the input element.

A common bug is to miss out a name value on an input, or to add the ‘wrong’ name value such that the server does not process the form correctly.

Checking the results on the server is very important.

Test Ideas:

  • check that every input element has a name, if it is expected to be processed by the server. input:not([name])
  • change the names on input elements or remove the names and see how the server side processing copes with the malformed form.

Form Validation

Required

When a form is submitted, some of the input types provide some validation protection e.g. email, url, etc.

The validation is only applied when a value is entered in the field.

In order to make a field mandatory an HTML designer can use the required attribute.

e.g.

<input type="text" name="author" required/>
<input type="text" name="title" required="yes/>
  • cssSelector: '[required]'

The ‘required’ attribute prevents a form being submitted when any input field (input, select), with this attribute present, does not have a value.

NOTE: the required attribute does not need a value, and any value can be used for the attribute e.g. required="required", "required="blue apples"

Like any other boolean attribute, I’m suspicious if a required attribute has a value, this often means that the people working on the front end don’t fully understand HTML and may indicate that I need to look at the implementation of the GUI more closely. e.g. required="false"

Test Ideas:

  • Try removing any ‘required’ attribute and then submit the form without a value in the field.
  • Try removing the field element completely and see what the backend server does.

Related MDN links

Hidden Fields

Amend a Hidden Field:

  • Using “The Pulper” - online here
  • Switch to a version of the app which supports book amendments
    • Choose a version number from the Admin menu drop down
  • Visit a book amendment page e.g.
  • This form has hidden fields, what happens if you amend the value?

View a Hidden Field:

  • Using “The Pulper” - online here
  • Visit a book amendment page e.g.
  • Amend the type of field from ‘hidden’ to ’text’

Text Fields

Invalid Values

Change Form fields to text and enter invalid values.

  • Using The Pulper find it online here
  • Select a Book and use the Amend form e.g.
  • Change the various form fields to ’text’ and enter invalid values.