How to Test a Text Field

I saw a blog post from @maaret not too long ago about How Would You Test a Text Field?

As you might have guessed, I really like these “How to Test” questions. I love the ideas that are generated around them and the discussions we have.

If I were to answer this myself, the first two things that would spring to mind are more the “What I would use to test a text field”. I would have to have the big list of naughty strings to hand! I would also have something like PerlClip or some other type of random string generator ready to quickly generate text of known length.

What about you? How would you test a text field?

How is copy-pasting supposed to work in the field: text only, with formatting, with media?
formatting as markup or WYSIWIG?
word wrap, resize, sensible scroll wheel and scroll bar behaviour…
keep focus when I’d expect it to
word wrap as display or by inserting CRs?
word wrapping changes when resizing?
what if you paste in a spreadsheet/table, how does that show?
when you copy out of it, again how does that work into other editors: notepad, Word, web pages?
How does it handle OSKs? Do they obscure important controls?
Can the box auto-expand over other items if you enter a lot?

1 Like

If it has a default or pre-filled value from some previous editing of that field, does that always come in correctly, is it already “select-all”-ed (should it be? )?

1 Like

I have an Excel file with columns corresponding to random fuzz type data that can break a UI textfield or command line. You may find it useful.


As is typical of me, I would start with asking questions about the text field. What is it for? Why am I entering text? What are the limits of the text I am entering? Should I expect an output? If so, what? Is the text field in an app? in a website? on an interface with an embedded system (think IoT)?

At some point, I should know enough to create test data, then the tools can come into play.

A handy mindmap

Another interesting thought experiment:
Someone puts a text field in front of you and gives you the assignment to test the field. You know nothing about the text field besides the name of the field is “text field”. How would you test this field?


Mindmaps are always something I struggle with. I’ve seen many people use them effectively but I’ve never managed to do so myself I don’t think.

1 Like

It is interesting to read this type of questions and even this article and see functional tester (beginner or advanced) answers.
I, just as you, enjoy reading various opinions on this topic types.

So one of the first rules of testing…Ask questions about the context.

I would try to understand what is a text field to that person asking.
Are we talking about a part of a text inside a paragraph? a text on a field(label)? a text inside a box(placeholder)? a text using a lawn mower on a field of grass? a text on a paper surrounded by a margin?

What is the person trying to figure out from me?
Is it how I think about a problem, how I find ideas, how I would write a test in TDD for that, how I would automate a check for that field, how I would present that feature in a demo, how I write test-cases…

What is relevant to the person asking the question?
How much time do I have to answer it?
How would the answer have to be? spoken/paper/digital/chatted?

From what perspective do I test?
What am I when I test it? A tester, a user, a person buying the software…?

And so on…
What interaction can I do with this text field?
Context about hardware and software of this field?
What does this field integrate with?
Who, how many, why, when…etc. users use this field?
And on…


I once went on a final interview where I expected to talk about salary and a start date and was hit with a question that haunts me even until today. How would a test the twitter textbox? I’ll be honest and tell you that I froze. Since then that question has haunted me for a long time. I was so disappointed in myself that I never followed up on answering that question for myself.

This question brought back that nightmare for me. I wish I could go back to that day and shake myself and tell myself to get the context of such a question and from there begin to develop a point of attack. Anyways, great points made so far on how to test.

What would I do?
Well, considering a context similar to the Twitter textbox, I would consider the following:

  • First, I’d gather information on what features the textbox has, in the case of twitter I would consider the following features list to start my exploratory test session:

    • I18N compliant
    • Hashtag and name tag referencing
    • string limits
    • string counter (not really part of the textbox but very much tied to it)
    • handling of emoji
    • interaction with other plugins such as Grammarly
    • accessibility compliant
  • In order to explore the features listed above, I would consider the following types of tests:

    • exploratory testing to cover string limits, string counter, handling of emoji, interaction with other plugins, accessibility compliant, i18n handling, and many other ideas that will pop into my head as I explore.
    • localization testing and string manipulation to cover I18N compliance
    • performance testing (load, stress, volume) in order to cover hashtag and name tag referencing.
    • light security testing to cover SQL injection, access to textbox as an unauthorized user, etc.

I’m sure there is much more that could be covered but this is just a quick analysis of what I would start doing to test a textbox similar to the Twitter textbox. :slight_smile:


Hey everyone,

Great ideas. I decided to compile them in a Google Doc with a few of my on ideas because I’ve been wanting a better way to reference test ideas for a while.

Comments and suggestions for a better format for something like this very welcome :slight_smile:

(permissions updated)

1 Like

Quick questions about the text box:
Is the text field the best input at that time?
What happends to the text that is input into it? Does it get read and used within the software? If yes, is the text box used/read by different parts of the software for differt reasons or always the same part of the software? If different, does the validation argument change between the different parts of the software.
What should happen if invalid data is entered?
Is there a standard entry format (think UK licence plates that generally follow a form but in reality can be anything within reason)?
Does it have to be used in multiple countries and therefore allow different languages to be entered?
Can the text in it be formatted?
Can the delete key be used in it?
Is it multilined?

Just a couple of questions I would be asking (sorry that some are repeats of other peoples.

1 Like

The main focus of functional testing services companies is to enhance the quality of product in all respects and we have following ways to test a Text field:

  • Type only single character in the text field and observe the behavior after clicking Save button.
  • Type multiple characters in the text field and observe the behavior after clicking Save button.
  • Type blank space in the text field and observe the behavior after clicking Save button.
  • Validate the text field by adding ASCll characters.
  • Provide blank text at the end of the syntax and observe the behavior after clicking Save button.
  • Validate the text field with lowercase/uppercase alphabets.
  • Insert special characters/Symbols in the text field and observe the behavior after clicking Save button.
  • Validate the text field with decimal numbers.
  • Insert spaces between words/characters in the text field and observe the behavior.
  • Try to cut/copy and paste the syntax from another location in the text field and observe the behavior.
  • Insert both negative and positive numbers in the text field.
  • Validate the text field by providing blank text at the beginning of the syntax.
  • Validate text field by providing different languages in text field.
  • Add the MAX number of the allowed characters.
  • Test the boundaries of the input field (MIN/MAX number).
  • In any case that the text field should receive a specific value, validate that the user can insert data that following the predefined validation pattern.
  • Do not enter any syntax as input (the submit button shouldn’t be allowed).

Hope this information will be helpful for you.



Recently, I’ve favored attempts to separate testing of interface components like a text box from the business functions that use the data collected from a text box. When I take that approach, the tests for the text box itself become much simpler and I can focus my time on the business functions.

Once the data collected in the text box has passed to the application, I can evaluate things mentioned above such as validations, where the data travels, and how it is used in other parts of the application. Ideally, I wouldn’t need the text box to execute this testing if there were simpler means to convey text to the business functions under test.

This topic is also very well covered in the BBST course Domain Testing: The Most Widely Used Test Technique.


If the string is associated with a field in a database table, there’s always this cautionary tale:


Good old Bobby Tables.

1 Like

Thanks for sharing. I am preparing to interview candidates for a couple of test positions, and think I will include this question. Your experience will inform my empathy - while this discussion helps sharpen my own skills.