When I first started in software testing, I found it fun to test text fields. It was entertaining to discover what would happen when I put too many characters in a field. But as I entered my fourth QA job and discovered that once again I had a contact form to test, my interest started to wane. It’s not all that interesting to input the maximum amount of characters, the minimum amount of characters, one too many characters, one too few characters, and so on for every text field in an application!
However, it was around this time that I realized that input validation is extremely important. Whenever a user has the opportunity to add data in an application, there is the potential of malicious misuse or unexpected consequences. Testing input validation is a critical activity for the following four reasons:
1. Security
Malicious users can exploit text fields to get information they shouldn’t have. They can do this in three ways:
- Cross-site scripting– an attacker enters a script into a text field. If the text field does not have proper validation that strips out scripting characters, the value will be saved and the script will then execute automatically when an unsuspecting user navigates to the page. The executed script can return information about the user’s session id, or even pop up a form and prompt the user to enter their password, which then gets written to a location the attacker has access to.
- SQL injection– if a text field allows certain characters such as semicolons, it’s possible that an attacker can enter values into the field which will fool the database into executing a SQL command and returning information such as the usernames and passwords of all the users on the site. It’s even possible for an attacker to erase a data table through SQL injection.
- Buffer overflow attack- if a variable is configured to have enough memory for a certain number of characters, but it’s possible to enter a much larger number of characters into the associated text field, the memory can overflow into other locations. When this happens, an attacker can exploit this to gain access to sensitive information or even manipulate the program.
2. Stability
When a user is able to input data that the application is not equipped to handle, the application can react in unexpected ways, such as crashing or refusing to save. Here are a couple of examples:
- My Zip code begins with a 0. I have encountered forms where I can’t save my address because the application strips the leading 0 off of the Zip code and then tells me that my Zip code has only four digits.
- I have a co-worker who has both a hyphen and an apostrophe in his last name. He told me that entering his name frequently breaks the forms he is filling out.
3. Visual Consistency
When a field has too many characters in it, it can affect the way a page is displayed. This can be easily seen when looking at any QA test environment. For example, if a list of first names and last names is displayed on a page of contacts, you will often see that some astute tester has entered “Reallyreallyreallyreallyreallylongfirstname Reallyreallyreallyreallyreallylonglastname” as one of the contacts. If a name like this causes the contact page to be excessively wide and need a horizontal scroll bar, then a real user in the production environment could potentially cause the page to render in this way.
4. Health of the Database
When fields are not validated correctly, all kinds of erroneous data can be saved to the database. This can affect both how the application runs and how it behaves.
The phone number field is an excellent example of how unhealthy data can affect an application. I worked for a company where for years phone numbers were not validated properly. When we were updating the application, we wanted to automatically format phone numbers so they would display attractively in this format: (800)-555-1000. But because there were values in the database like “Dad’s number”, there was no way to format them, therefore causing an error on the page.
Painstakingly validating input fields can be very tedious, but the above examples demonstrate why it is so important. The good news is that there are ways to alleviate the boredom. Automating validation checks can keep us from having to manually run the same tests repeatedly. Monkey-testing tools can help flush out bugs. And adding a sense of whimsy to testing can help keep things interesting. I have all the lyrics to “Frosty the Snowman” saved in a text file. Whenever I need to test the allowed length of a text field, I paste all or some of the lyrics into the field. When a developer sees database entries with “Frosty the Snowman was a j”, they know I have been there!
The sad thing about Input Validations is that each of us plans these from scratch (or our own experience) rather than holding a set of common "field proven" tests based on what others have already learnt – even though common guidelines can be applied to most field types.
And also while Input Validation is simple and needed, the harder and more error prone part is Output Validation, of calculated data.
I'm glad you found it useful!
Halperinko, you are right that input validation testing is made easier by having a standard set of tests to run through for each field. I have a routine I use that isn't automated, but certainly could be. That sounds like an interesting side project! Output validation is something I haven't done much, because I haven't been responsible for application areas that do calculations. But I work with people who do test in those areas, and I think this would be a great future blog topic!
Pretty article! I found some useful information in your blog, it was awesome to read, thanks for sharing this great content to my vision, keep sharing. Need to learn
Security Testing Services
Test Automation Services
Software Testing Services
Compatibility Testing Services
Regression Testing Services