Forms
Part of No-code app testing
Testing invalid input and missing information
Check how a no-code app handles blanks, invalid values, error messages and saved records across the write routes people use.
Test invalid input by stating a field's rule, entering a value that breaks it, then checking the message and the saved record. Test missing information separately. A blank may be acceptable while work is in progress but unacceptable when the record is closed. Set the task's expected outcome before trying the form.
Distinguish an error from an unknown
In a hypothetical facilities form, a counted quantity might have to be a non-negative number at submission. A supervisor's decision could remain blank until review. A count of 0 is a known value; a blank count means the value is unavailable. Agree on those meanings before testing.
| Case | Question to answer |
|---|---|
| Blank | Is it allowed at this workflow stage? |
| Known zero or “No” | Is it saved as an answer rather than treated as missing? |
| Wrong type or format | Does the app identify the field and describe the problem? |
| Outside an agreed range | Is it rejected, or is there an authorised exception? |
| Hidden conditional field | What happens to an earlier value when the condition changes? |
Set actual required fields, ranges and exceptions with the app owner. This is a test-case list, not a universal rule for business data.
Check the feedback and saved result
Enter one invalid value at a time, then try plausible combinations. Can a person find and correct each error without re-entering unrelated information? Does the configured app retain valid answers?
W3C's web-content error-identification criterion says an automatically detected input error must identify the affected item and describe the error in text. An unchanged form with no explanation is insufficient.
After a valid correction, inspect the saved record. An accepted screen input does not prove the intended row changed. If the save's outcome is uncertain, the user needs a way to check for the record before submitting again.
Test each permitted write route
List the routes that can change the field: form, edit screen, action, import and integration, where available. A rule shown in one form may not govern another route. Browser-side validation in a web form can be bypassed, so a rule needed for every write also needs an appropriate receiving-side control.
For each available AppSheet route that can change the field, test an invalid and missing value, then check the feedback and saved result.
In a Power Apps canvas form, SubmitForm checks required fields and available constraints before submission, then runs success or failure behaviour according to the result.
Record what happened
For each case, note the role, starting record, input, expected message, expected saved value and observed result. State whether the app rejected the input, saved an invalid value, lost a valid value or left the result unclear. After a correction, repeat the focused case and any other route relevant to the fault.
