Any text field in developed software seems to be simple and clear functionality. And the process of it testing comes to a simple check of correct filling of fields. But it is only at first glance.

[highlight dark=”no”]You need to carefully check the correctness of the text field because it’s possible to gain unauthorized access to the database through it! [/highlight]

During functional testing, validation of text fields is the first test that can prevent manipulations with user’s files and data. Also, it is some kind of protection from the harmful information in the database.

Such files with viruses can cause a problem with web product functioning on the client’s and server’s sides. And finally, [highlight dark=”no”]correct validation allows avoiding attacks of cross-site scripting and harmful SQL injections by hackers. [/highlight]

There are many ways to check text field performance. We will highlight the most important tests that any QA specialist must conduct.

Text Field Testing Without Specifications

So, let’s imagine that we have to check a text field, and there’s no particular information about it in project specifications.

In this case, it’s possible to do the following:

• Click on the Submit button without previous text field filling.
• Click on the space bar a few times, and then click on the Submit button.
• Analyze how many characters you can enter in the field, and then press the Submit button.
• Enter the minus sign and as many numbers as you can, and then tap Submit.
• Enter all the possible special symbols and click Submit. If you see a message with an error, try to analyze it.
• Try to enter the symbols that don’t technically correspond with ASCII, different emoji icons, and click Submit. If you see a message with an error, try to analyze it.
• Try the features of the cross-site scripting. For this, you should enter such a script: <script>alert(“I hacked this!”)</script>. If there is a pop-up after clicking Submit, it means that this field is vulnerable to XSS attack (cross-site scripting attack).
• Check if it’s possible to use SQL injections. Enter FOO’); DROP TABLE USERS. But don’t do this with databases of those sites that are in production.

Text Field Testing Based on Technical Documentation

Let’s imagine that we have some information about text fields, we know what to enter in these fields, and what limits there are.

So, what exactly can we test?

• Entering a value that is different from the expected one. For example, if this field should contain some price value (numbers), try to enter some words or dates.
• If the field is designed for entering strings, try to enter the string that is 1 symbol shorter/longer than it should be; or enter a minimum/maximum number of symbols.
• In the case with a field of number type that is expecting an integer, try to enter a number with a decimal point.
• If the number field is expecting a number with float point, try to enter a value with a comma, or a value that begins with a comma.
• If it is a date field, try to enter the minimum/maximum date, 1 day before the minimum/over the maximum date, or date 100 years more or less than established technical limits.
• For such a field, you can also try to enter an irrational date, for example, 15/15/19.
• If the field is expecting time, try to enter an irrational time, for example, 24:21.
• In the case with a field that is expecting a phone number, check the possibility of entering a number that doesn’t conform to the set format.

For all these tests you have to be confident about the type of error messages you get, and also you have to be sure that all the messages are correct when you submit valid data.

Text Field Testing + Automation

In this case, you cannot avoid test automation.

If tester conducts all the manual tests, probably there’s no need for test automation. What’s more, many fill-out forms have several fields. It means that a lot of tests for each separate field require lots and lots of time for their execution.

Nevertheless, there are some suggestions about the things that can be automated:

1. Entering an empty string and zero value;
2. Entering the value that meets technical specification criteria (so-called happy script);
3. Capability to enter a maximum number of symbols and/or minimum value;
4. Entering data that is more than maximum;
5. Entering data that is less than a minimum from the specification.

Obviously, this is a non-exhaustive list of all the possible tests for text fields. But this list can be used as a basic test suite that must be executed while working with text fields.

Testers should never take the developer’s word for thу fact that everything works fine and there’s no need to perform monotonous tests once again. Don’t forget that if a client finds some technical vulnerability, a tester will be responsible for this.