Test what happens when a form cannot be completed.

For this exercise, name is required, quantity allows integers from 1 to 10, and description may be empty. Write these rules before testing so unexpected behaviour does not accidentally become the requirement.

Try an empty quantity, 0, 1, 10, 11 and 1.5. Under this contract, boundary values 1 and 10 are accepted; the others require the intended invalid-value behaviour.

Submit with an empty name. Expect a message identifying the field and explaining what is missing. “An error occurred” does not distinguish incomplete data from an unavailable service.

Correct the name. Check that other fields retain their values and that the message clears or updates on validation. Navigate through the fields with a keyboard too.

MDN explains that browser validation does not replace server validation. In a real application, ask the builder where rules are enforced when data arrives.

In an authorised test environment, the team can submit an out-of-range quantity directly to the entry point and check that it is rejected there too. A disabled button alone does not establish this protection.

Arrange a simulated save failure with the team in testing. The form should not claim that a request was created without confirmation. Define the message and what the person can do with the data already entered.

Record field, input, expected outcome and observed outcome. After a fix, repeat boundary values and a complete valid case. Keep results with acceptance criteria.