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.
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?
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? )?
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.
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?
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.
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
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.
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).
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.
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.
This list should be used to test almost any âTextâ filed objects in your application:
If the text field should receive only numbers, try to write any other character.
Do not enter any syntax as input (the submit button shouldnât be allowed).
Try to Add more characters than the MAX allowed number of characters.
Validate the text field with both lowercase and uppercase alphabets.
Test the boundaries of the input field (MAX number â 1).
Test the boundaries of the input field (MAX number + 1).
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.
Test the boundaries of the input field (MAX number).
Test the boundaries of the input field (MIN number).
Try to copy -> paste syntax from another location.
Exhaustive plan. Nice. A very good start if you have a lot of time available to you. My only pain with this approach, is that it ignores the UX, ignores the Business case, and Business value. And probably will be checking things you know are not valuable early on. Often on something like this, you are allowed about 2 minutes. Whether the field correctly saves/persists is sometimes more important to check first, if anything. Most other defects not security related can be fixed quicker, later, please see XKCD graphic higher up.
