Testing practice: For Test empty and boundary input, define a reproducible starting state, perform one controlled change at a time and record the result. Good testing evidence helps another person repeat the same path without guessing what happened.
Evidence quality: A useful report separates observation from theory. Record version, device context, steps, expected result and actual result while removing passwords, authentication codes and unrelated personal information from evidence.
Test empty and boundary input
Try required fields empty and test minimum or maximum lengths where rules exist.
Validation should explain the problem near the relevant field.
Test realistic invalid values
Use malformed email, unsupported characters or invalid date combinations based on the form's purpose.
Avoid destructive or abusive payloads unless you are authorized for security testing.
Check keyboard interaction
The on-screen keyboard can cover fields, errors or the submit button.
Test small screens and different keyboard types.
Protect against double submission
Slow networks encourage repeated taps.
Disable or safely handle duplicate submits while the first request is unresolved.
Preserve useful input
After a recoverable validation error, unrelated correct fields should normally remain available.
Test that users do not have to re-enter an entire form unnecessarily.
Common mistakes to avoid
- Testing only valid input.
- Ignoring keyboard overlap.
- Allowing repeated tap duplicates.
Practical checklist
- Test empty fields.
- Test boundaries.
- Use small screens.
- Test slow submission.
- Check field preservation.
Frequently asked questions
Should every error clear the form?
Usually no; preserving valid input reduces user frustration.
Why test keyboard overlap?
Mobile screens are small and the keyboard can hide controls.
Can I use attack strings?
Security testing requires explicit authorization and a suitable environment.