How to Write Test Cases for a Text Field / Input Box

If you need solid test cases for a text field, stop thinking of the field as "type something and move on." A text input is a contract: what users may enter, what the UI accepts, what the server stores, and what every downstream feature will later trust. Most form bugs start as weak field assumptions. A max length mismatch between UI and database, a trim rule that deletes meaningful spaces, or a validator that allows characters the API cannot handle can break registration, search, payments, and admin tools.

This guide shows how to design test cases for a text field or input box from scratch. You will get a rule checklist, equivalence and boundary patterns, positive and negative examples, security and accessibility cases, copy-paste and mobile behaviors, and a reusable suite template. The same method scales from a simple nickname box to critical identifiers.

Why Text Field Testing Is Higher Leverage Than It Looks

Teams often under-test single inputs because the control looks trivial. In reality, one field can touch:

• Client validation.
• Server validation.
• Database constraints.
• Search indexing.
• Rendering in multiple pages.
• Logs and analytics.
• Security filters.
• Accessibility labels and error announcements.

A defect in a "simple" city field may break shipping labels. A defect in a notes field may open XSS in an admin panel. Field-level discipline prevents expensive multi-feature failures.

Step 1: Identify the Field Contract

Before writing cases, write the contract in plain language.

Example contract for a Display Name field:

Required. 2 to 40 characters. Letters, spaces, hyphen, and apostrophe allowed. Leading and trailing spaces are trimmed. Emoji rejected. Unique per account. Shown on public profile.

From that contract you can already derive dozens of precise checks.

Contract checklist

Ask:

1. Is the field required or optional?
2. What is the business purpose of the value?
3. Minimum length?
4. Maximum length?
5. Allowed character set?
6. Disallowed character set?
7. Case sensitivity?
8. Trim rules for leading, trailing, and internal spaces?
9. Normalization (Unicode form, lowercasing)?
10. Uniqueness constraints?
11. Dependent fields or conditional required rules?
12. Where is the value displayed later?
13. Is it editable after save?
14. Does paste behave differently from typing?
15. Mobile keyboard type and autocomplete attributes?

If product docs are silent, list assumptions and get confirmation. Do not invent silent trim behavior.

Step 2: Build Equivalence Partitions

Equivalence partitioning keeps the suite lean. Group inputs that should behave the same, then pick representatives. This pairs directly with boundary value analysis and equivalence partitioning.

Example partitions for a required alphanumeric username (3-20)

Partition	Examples	Expected class
Empty	``	Invalid required
Too short	ab	Invalid min length
Valid min	abc	Valid
Valid typical	qa_user_01	Valid
Valid max	20 allowed chars	Valid
Too long	21 chars	Invalid
Illegal character	qa user!	Invalid
Only spaces		Invalid
Reserved word	admin if reserved	Invalid
Existing username	already taken	Invalid uniqueness

You do not need 50 valid typical names. One strong representative per partition is enough unless risk demands more.

Step 3: Add Boundaries Explicitly

Boundaries catch off-by-one mistakes.

For length min=3 and max=20, prioritize:

• 2 (min-1)
• 3 (min)
• 4 (min+1) optional if time allows
• 19 (max-1) optional
• 20 (max)
• 21 (max+1)

Also consider:

• Empty vs single space vs multiple spaces.
• Max multibyte characters if max is character count not byte count.
• Grapheme clusters such as emoji composed of multiple code points.

Field: bio
Rule: max 160 characters
Boundary cases:
1. 0 chars (if optional empty allowed)
2. 1 char
3. 160 chars
4. 161 chars
5. 160 emoji-heavy characters if emoji allowed

Clarify whether max means characters, graphemes, or bytes. This matters for Unicode.

Core Test Cases for a Text Field

Use this generic set and specialize it.

ID	Title	Data idea	Expected
TC-TXT-001	Valid typical value saves	Realistic valid string	Accepted and persisted
TC-TXT-002	Required field empty	Blank	Required error, not saved
TC-TXT-003	Whitespace only when required	Spaces/tabs	Rejected or trimmed to empty then rejected
TC-TXT-004	Minimum length accepted	Exact min length	Accepted
TC-TXT-005	Below minimum rejected	min-1	Rejected
TC-TXT-006	Maximum length accepted	Exact max length	Accepted
TC-TXT-007	Over maximum rejected	max+1	Rejected before or at server
TC-TXT-008	Allowed special characters	Hyphen/apostrophe if allowed	Accepted
TC-TXT-009	Disallowed characters	Symbols not in allowlist	Rejected
TC-TXT-010	Leading/trailing spaces	value	Trimmed or rejected per rule
TC-TXT-011	Internal spaces	Mary Jane	Accepted if multi-word allowed
TC-TXT-012	Paste valid value	Paste from clipboard	Same as typing valid
TC-TXT-013	Paste overlong value	Paste max+N	Rejected or truncated per rule
TC-TXT-014	Clear existing value	Delete all and save	Required error or empty optional save
TC-TXT-015	Edit and update value	Change old to new valid	New value persisted

Detailed example

Test Case ID: TC-TXT-006
Title: Verify text field accepts exact maximum length input
Requirement Reference: PROFILE-DISPLAY-NAME
Priority: High
Preconditions:
  - User is logged in on profile edit page
  - Display name max length is 40
Test Data:
  - 40 character valid name string
Steps:
  1. Open display name field.
  2. Clear existing value.
  3. Enter exactly 40 allowed characters.
  4. Save profile.
  5. Reopen profile edit page.
Expected Result:
  - No validation error on save.
  - Success confirmation appears.
  - Stored display name equals the 40 character value after any documented normalization.
  - Public profile shows the same display name.

Field Type Variants and Extra Cases

Not every text box is free text. Specialize.

Email-like text field

• Valid standard email.
• Missing @.
• Missing domain.
• Multiple @.
• Uppercase normalization.
• Plus addressing.
• Domain typos if product warns.

Numeric text field (amount, age, quantity typed in text box)

• Digits only valid.
• Letters rejected.
• Decimal rules.
• Leading zeros.
• Negative values if disallowed.
• Thousand separators if allowed.
• Min/max numeric bounds, not only string length.

Phone text field

• Country code required or not.
• Formatting masks.
• Copy paste with spaces and dashes.
• Too short/too long.

URL field

• https:// valid.
• Missing scheme.
• Spaces.
• Javascript URLs if dangerous.
• Max length.

Search box

• Empty submit behavior.
• Trim behavior.
• Special operators if supported.
• Latency and no-results UX.

Password field

• Masked display.
• Paste allowed or blocked.
• Spaces preserved.
• Complexity rules.

Cross-link specialized form suites when the field sits inside them: test cases for registration form and test cases for login page.

Whitespace, Trimming, and Normalization Cases

Whitespace bugs are everywhere.

Case	Input	Questions to answer with expected results
Leading spaces	alex	Trim or reject?
Trailing spaces	alex	Trim or reject?
Internal double spaces	Alex Buyer	Collapse, preserve, or reject?
Tabs	alex\t	Convert, reject, or preserve?
Newlines in single-line field	pasted multiline	Reject or strip?
Non-breaking space	\u00A0alex	Treat as space?
Zero-width characters	hidden chars	Reject for identifiers?

Your expected result should state both UI validation and stored value. Many systems accept visually identical values that differ in bytes, then fail uniqueness checks later.

Unicode, Locale, and International Input

Modern products receive global input whether planned or not.

Test ideas:

• Accented letters: José, Müller.
• Non-Latin scripts: Hindi, Arabic, Chinese samples if allowed.
• RTL names in LTR layout.
• Emoji: single emoji, emoji sequences, skin tone modifiers.
• Mixed script identifiers if security forbids them.
• Turkish case mapping issues around i/I if lowercasing emails or codes.

ID	Title	Expected direction
TC-TXT-030	Accented valid name	Accept if letters allowed
TC-TXT-031	Arabic name in allowed free-text	Accept and display correctly
TC-TXT-032	Emoji in restricted identifier	Reject
TC-TXT-033	Emoji in optional notes	Accept if free text allows
TC-TXT-034	RTL string display	No broken layout, readable

If the database column or PDF renderer cannot handle the character set, that is still a product defect relative to stated support.

Security Test Cases for Text Inputs

Any text field that is stored or rendered needs security attention.

Payload samples:
<script>alert(1)</script>
"><img src=x onerror=alert(1)>
' OR '1'='1
{{7*7}}
${7*7}
{{constructor.constructor('alert(1)')()}}

ID	Title	Expected
TC-TXT-040	Script tags saved safely	No execution in app surfaces
TC-TXT-041	HTML rendered as text where required	Escaped output
TC-TXT-042	SQL-like string	No auth or query bypass
TC-TXT-043	Template injection sample	No expression evaluation
TC-TXT-044	Very large payload (e.g., 100KB)	Rejected or handled without crash
TC-TXT-045	Control characters	Rejected or sanitized per policy

Also verify admin pages, exports, tickets, and emails if they render the field. XSS often appears one screen away from the input.

UX and Interaction Cases

Typing and controls

• Cursor position after error.
• Max length attribute prevents extra typing if that is intended.
• Counter updates live (12/40) if present.
• Undo/redo in browser still leaves valid state.
• Autocomplete suggestions can be selected.

Paste behavior

• Paste into empty field.
• Paste replacing a selection.
• Paste maintains or strips formatting from rich sources.
• Drag-and-drop text if supported.

Disabled and readonly

• Disabled field cannot be edited.
• Readonly field can be focused and copied if required.
• Values in disabled fields are not lost unexpectedly on submit of other fields.

Error UX

• Error appears at the right time (blur/submit).
• Error disappears when input becomes valid.
• Multiple errors remain understandable.
• Error text is specific: "Use 3 to 20 letters" is better than "Invalid."

Accessibility Test Cases

Text fields are accessibility critical.

ID	Title	Expected
TC-TXT-050	Visible label exists	Label text associated with input
TC-TXT-051	Placeholder not only label	Accessible name still present without placeholder
TC-TXT-052	Required state exposed	Assistive tech indicates required
TC-TXT-053	Error announced	Error linked via aria or equivalent
TC-TXT-054	Keyboard only complete	Can focus, type, submit without mouse
TC-TXT-055	Focus order logical	Tab order matches visual order
TC-TXT-056	Contrast of text and errors	Meets target contrast guidance

A field can pass functional tests and still fail users who rely on keyboards or screen readers.

Client vs Server Validation Cases

Never assume UI validation is enough.

1. Enter invalid value in UI and confirm blocked.
2. Bypass UI (proxy tools or API call) with the same invalid value.
3. Confirm server rejects and does not persist.

Layer	What to verify
Client	Fast feedback, correct message, no useless server round trip for obvious errors
Server	Authoritative enforcement, safe status codes, no partial writes
Database	Constraints align with business max lengths and nullability

Mismatch example: UI max 40, API accepts 255, DB column 50. Users with API clients create values UI cannot edit later. Write a case that detects this class of inconsistency when you have multi-layer access.

Persistence and Downstream Display Cases

A value is not correct only because the form said success.

After save, verify:

• Reopened form shows saved value.
• Profile header shows saved value.
• Search by that value works if searchable.
• Admin grid shows value.
• Export/CSV preserves characters.
• Truncation in cards does not corrupt meaning without accessible full value.

Title: Verify display name persists and appears on public profile
Steps:
  1. Set display name to Valid Name 123 within rules.
  2. Save.
  3. Refresh.
  4. Open public profile URL.
Expected:
  - Edit form shows Valid Name 123 (after normalization).
  - Public profile shows the same visible name.

Conditional Text Fields

Some inputs appear only under conditions.

Examples:

• "Other" reason text box appears when reason = Other.
• Company name required when account type = Business.
• Apartment field optional unless shipping type needs it.

Cases:

ID	Title	Expected
TC-TXT-060	Hidden when condition false	Field not required, not blocking submit
TC-TXT-061	Shown when condition true	Field visible
TC-TXT-062	Required when shown	Empty blocks submit
TC-TXT-063	Value cleared or retained on hide	Matches product rule
TC-TXT-064	Toggle condition twice	No stale validation errors

Conditional fields are frequent sources of "ghost required" bugs.

How Many Test Cases Are Enough for One Field?

Use risk.

Field risk	Suggested depth
Low: optional internal notes	Valid, empty, max, basic XSS sample
Medium: display name	Full length bounds, charset, trim, persistence, accessibility
High: email, coupon, account id, amount as text	Full partitions, security, server-side, uniqueness, downstream

A single high-risk field can deserve 20-40 cases. A low-risk field may need 5-8. Document out-of-scope decisions so reviewers know you were intentional.

Reusable Template for Any Text Field

Field name:
Business purpose:
Required: yes/no
Min length:
Max length:
Allowed characters:
Disallowed characters:
Trim/normalize rules:
Unique: yes/no
Dependent conditions:
Surfaces where displayed:

Cases:
1. empty
2. whitespace only
3. valid typical
4. min-1 / min / max / max+1
5. allowed specials
6. disallowed specials
7. leading/trailing spaces
8. unicode sample
9. paste overlong
10. XSS/SQL sample
11. save and reopen persistence
12. accessibility label/error
13. server-side rejection of invalid

This checklist is faster than blank-page writing and improves consistency across the team. For overall case structure quality, revisit how to write test cases.

Common Mistakes When Writing Test Cases for a Text Field

Mistake 1: Only testing one valid and one invalid value

That misses boundaries, trim rules, and charset defects.

Mistake 2: Asserting UI message only

Always include whether the value was stored.

Mistake 3: Ignoring paste and mobile

Many users never type character by character.

Mistake 4: Forgetting downstream screens

The injection or truncation bug may appear in admin, email, or PDF.

Mistake 5: Treating all fields like free text

Identifiers, amounts, and codes need stricter partitions.

Mistake 6: No Unicode coverage in global products

ASCII-only testing is incomplete for modern user bases.

Mistake 7: Duplicating cases without partitions

Twenty similar valid names waste execution time.

Mistake 8: Not updating cases when validation rules change

Field rules evolve. Suite rot creates false failures and false confidence.

Sample Mini Suite for a Required Display Name (2-40)

1. Empty rejected.
2. One character rejected.
3. Two characters accepted.
4. Forty characters accepted.
5. Forty-one characters rejected.
6. Internal space accepted.
7. Leading spaces trimmed or rejected per rule.
8. Digits behavior per rule.
9. Emoji rejected if not allowed.
10. XSS payload escaped.
11. Save and reopen persistence.
12. Keyboard accessible label and error.
13. Duplicate name rejected if unique.
14. Server rejects overlong via API.

These fourteen cases already form a serious field pack.

Automation Tips for Text Field Checks

Automate stable rules:

• Required empty.
• Min/max length.
• Representative invalid charset.
• Persistence after save.

Keep manual or exploratory:

• Nuanced rendering across many locales.
• Visual truncation aesthetics.
• Novel unicode edge clusters.

Data-driven tables work well:

input, expected
"", required_error
"A", min_length_error
"AB", success
"<41 char string>", max_length_error

Avoid asserting exact full sentences if marketing changes copy weekly. Assert error state and rule meaning, or use stable translation keys when available.

Practice Drill

Pick three fields on any app: search box, profile name, and checkout coupon.

For each field, spend 15 minutes to:

1. Write the field contract as you understand it.
2. List partitions.
3. Write 8 test cases.
4. Mark the single highest risk case.
5. Note one open question for product or dev.

Then execute them. You will quickly see where docs and behavior diverge. For repeated drills in a competitive setup, open QABattle battles and practice turning tiny UI controls into complete coverage notes.

Review Checklist for Text Field Suites

• Contract documented.
• Required/optional covered.
• Min and max boundaries covered.
• Charset allow and deny covered.
• Whitespace policy covered.
• Unicode stance covered for product audience.
• Paste path covered.
• Security sample covered for stored fields.
• Persistence and downstream display covered.
• Accessibility label/error covered.
• Client and server enforcement considered.
• Priority reflects field risk.

Conclusion

Great test cases for a text field are really tests of a data contract. They check what can enter the system, how it is normalized, where it is shown, and whether invalid values are blocked at every layer that matters. Start from the field rules, partition inputs, hit boundaries, include whitespace and unicode reality, and verify persistence rather than only on-screen messages.

If you apply this method field by field on high-risk forms, your overall product quality rises faster than writing one giant end-to-end path that types perfect data once. Small inputs carry large consequences. Test them with that respect.