Testing a Text Field

A text field in an application seems so ordinary, and yet it is one of the most important things we can test.  Why?  Because text fields provide an entryway into an application and its underlying database.  Validation on a text field is what keeps lousy data from getting into the database, which can cause all sorts of problems for end users and engineers. It can also prevent cross-site scripting attacks and SQL injection attacks. 

There are a myriad of ways to test a text field, and I will be outlining several in this post.  First, let’s imagine that we are testing the text field with absolutely no information about what it does:

  • Click Submit without filling in the text field
  • Press the space bar several times in the text field and then click Submit
  • See how many characters you can fit in the text field and then click Submit (an excellent tool to count characters is https://lettercount.com)
  • Fill the field with as many numbers as you can and then click Submit
  • Add a negative sign, fill the field with as many numbers as you can and then click Submit
  • Enter every non-alphanumeric field on the keyboard and click Submit.  If you get an error, see if you can narrow down which key (or keys) is causing the error.
  • Enter in non-ASCII characters and emojis and click Submit.  If you get an error, see if you can narrow down which symbol (or symbols) is causing the error.
  • Try cross-site scripting by entering in this script: <script>alert(“I hacked this!”)</script>  If on Submit, you get a popup message, then you know the field is vulnerable to cross-site scripting.
  • Try a SQL injection attack, such as FOO’); DROP TABLE USERS; — (Don’t try this on your Production database!)
Next, let’s assume that you have some knowledge about what is supposed to be entered into this text field and what the boundaries are on the data:
  • Try putting in a value that is a different data type from what is expected; for example, if this text field is expecting a value of currency, try putting in a string or a date
  • If the field is expecting a string, try putting in a string with one fewer characters than is expected, one more character than is expected, the lower limit of characters that is expected, the upper limit of characters that is expected, and twice the maximum number of characters expected
  • If the field is expecting a numeric value, try putting the maximum value, the minimum value, a value above the maximum, a value below the minimum, and a value twice the maximum value
  • If the field is expecting an integer, try submitting a value with a decimal point
  • If the field is expecting a float, try submitting a value with two decimal points and a value that begins with a decimal point
  • If the field is expecting a value of currency, try submitting a value with more than two digits after the decimal point
  • If the field is expecting a date, try putting in the maximum date, the minimum date, one day over the maximum date, one day before the minimum date, and a date one hundred years above or below the limit
  • For date fields, try entering a date that doesn’t make sense, such as 6/31/17 or 13/13/17  (There are many more ways to test date fields; I’ll touch on this in a later post)
  • If the field is expecting a time, try entering a time that doesn’t make sense, such as 25:15
  • If the field is expecting a phone number, try entering a number that doesn’t conform to the expected format (There are many, MANY more ways to test phone numbers; I’ll touch on this in a later post as well)
For all of the above tests, find out what sort of error message you are supposed to be receiving, and verify that you are getting the correct message.
Finally, let’s think about automation.  Assuming you have very thoroughly tested your text field manually, it’s probably not necessary to automate every single one of your tests.  Moreover, most forms have more than one text field, and having many tests for each individual field could result in many time-consuming tests.  But here are some suggestions for what you might want to automate:
  • submitting a null value
  • submitting an empty string 
  • submitting a value that meets the criteria (the “happy path”)
  • submitting the maximum number of characters or maximum value
  • submitting the minimum number of characters or minimum value
  • submitting just above the maximum characters or value
  • submitting just below the minimum characters or value
This list of tests is not meant to be completely exhaustive; it’s just a way to get you to start to think about the vast number of tests you can run on a single field.  Don’t ever assume that the developer who coded the field has put in the appropriate validation; check it for yourself!  I tested a date field once where there was a limit put on the year that could be entered so it couldn’t be before 1900 or after the present year.  While I did receive the appropriate message when I entered a value of 1880, I discovered that I could enter a date from the year 1300!