The hidden complexity of input fields: All the questions I ask before I trust it
Text boxes and input fields are everywhere in webpages and applications. They seem innocuous. After all, how could something as simple as a box where a user types text cause problems? But mix a simple element like this with human beings, and it's another story. These little boxes can be a challenge to test and a place where bugs lurk.
Input boxes are the foundation of many software functions. Login screens, search bars, fields connected to APIs, and other tools on the back end that the user never sees. So how do we test these powerful yet seemingly simple elements? How do we find the bugs that may be lurking and provide value to the user?
Heuristics
Just like your average computer, our brains can be helped by using “applications” or shortcuts to help us make decisions. In testing, this often leads me to use heuristics, or general guidelines, to help get my brain going. I like to think of these a lot like writing prompts or items on a menu I can pull in when we need to test something. I don’t need to use every heuristic every time. You wouldn’t use every application on your computer just to check your email. However, having different options to choose from can help us get started when we need to test a new application.
Here are a few heuristics I find helpful when testing a freeform input box:
Purpose
What is this field designed to do? What role does it play in the user's journey with the software? This question can help us sort out what the expected behaviour should be in this case. From this information, we can decide which positive cases we want to try and also which negative cases or undesirable behaviour we might try to elicit from the field.
Input types: What types of info should the user be able to add to this field? Perhaps more importantly, what kind of input should they not be able to put in this field? Is this a field that should be restricted to letters or numbers? How about symbols? As much as designers often don't think that users will put undesirable inputs into fields, users often do. Trying to see what happens when different inputs are entered and what the outcome is can help us spot things that could be frustrating in the user's journey.
Output types: Ultimately, the whole point of an input field is for the user to interact with the software and to put information in the field so it goes somewhere. As testers, we need to figure out where this input is going. Is it being used by an API or a login process? How does this impact how the field should act? Are there success messages that need to be shown or some sort of information communicated to the user after they enter text into the field?
Interactions
What kinds of tools can be used with this field type? Also, what sorts of things are users going to be able to expect to do with this field as they use it?
Control types: What kind of interfaces are users using to interact with this field? Someone who navigates with their keyboard is going to have a totally different experience than someone who navigates with their mouse. Considering things like being able to resize the field or move around within it without a mouse can also be really interesting because it allows us to see what the limits of the field are.
Stress test: Is this the kind of box that someone is only supposed to enter a few words into, or is this something that they can fill with full paragraphs? If only a few words are allowed or necessary, perhaps the box needs to be gated to ensure that people don't add more to the field. However, if the field is truly freeform, what happens if you paste an entire page of text into the field? Does it handle this okay? Sometimes it's assumed that users won't actually do these things, but since there are as many ways to use a field as there are users, this is probably a poor assumption.
User Experience
What is it like for a human to use this field? Does it pose any barriers to them? What types of humans could find this field hard to use or difficult to understand?
Confusion: Ask yourself if there is something about this field that could confuse a user. What if this user had a visual impairment or was working in a language that they're not comfortable in? Is there anything about this field or the instructions around it that could be confusing? This is also a case where viewing the field on more than one screen can be helpful. Sometimes things that are perfectly understandable on a laptop become more difficult when you view them on a phone.
Accessibility: In many cases, testers use some sort of tool to scan for basic web content accessibility guidelines (WCAG) and then leave it at that. However, accessibility is so much more than this. We should look for problems like input fields that involve a lot of clicks to get to, which could be a problem for someone with a motor impairment, or input boxes that are too small and can't be resized, which are all things to look for when determining if an input box is accessible. Asking yourself if the widest range of users possible is going to be able to use this text box is a great way to push the limits of what an element can do and ensure the best user experience.
Security
This is where the fun begins! If I were someone who wanted to use this tool for a negative purpose, what could I do with it? Are there ways a user could exploit this field or use it to damage the tools or data it is connected to in some way?
Bad Actors: We tend to think of users as the best and most perfect people who are paying for our product. However, there is a whole crowd of people out there on the internet looking to find ways to do things that are malicious with software. Ask yourself if a bad actor could paste some sort of script into this field. What happens if they paste something into it that is malicious? Where does it go, and are there controls in place to stop this from happening?
Some common examples here are:
SQL Injection, Cross Site Scripting, or Command Injection: Can a user input a malicious SQL fragment or inject JavaScript/HTML and commands that can manipulate the application's database or execute in other users' browsers when the input is displayed elsewhere?
URL Manipulation and Special character abuse - can the user manipulate the page URL to get to areas of the app or site they should not be in? Similarly, can they use quotes, semicolons, null bytes, or Unicode tricks used to break out of expected input handling or bypass filters?
Denial of Service via input Overflow and Buffer Overflow: Can the user use very long inputs, or inputs with huge payloads, deeply nested data, or computationally expensive patterns to slow down or crash the app
Logic and validation bypass: can the user submit unexpected data types or things like empty strings, extremely long strings, invalid emails, or negative numbers to trigger unhandled errors and crash the site or throw an error message?
Summary
You may notice that as you read this article, it really is a list of questions. This is because, for me, testing is really the process of asking questions of software and making sure that we are comfortable with the answers. In this case, I am hopeful that the above questions will help other testers come up with new ideas when testing these simple yet powerful elements that are so prevalent in so much software. Since input fields are so common, they seem very simple and like they would be either very easy or even very dull to test. However, there is a lot that a user can do with this one little field and a lot of ways a tester can push the limits of these fields and lower the risk of failure for the software team.
Further reading
I am not the only person to find these fields so interesting to test. Check out what these other testers had to say about the subject to learn more: