Negative testing checklist for web applications

Most test plans check that the app works when everything goes right. Real users do not behave that way. They paste a 900-character company name into a field built for 50, upload a 40 MB photo of a receipt, and type their email address with a space on the end. Negative testing is how you find out what your app does then.

Short version

• Negative testing means using wrong, missing, or hostile input to see if the app fails safely.
• A safe failure shows a clear message and keeps the user's work. An unsafe failure shows a stack trace, a blank page, or saves bad data.
• Five areas break most often: login, file upload, search, payment, and account settings.
• Test the boring inputs too: empty strings, spaces only, very long text, and negative numbers.
• Write down what you expected and what you got. That pair is the whole bug report.

---

What negative testing means

Positive testing checks the happy path. You enter a valid email, a valid password, and you get in.

Negative testing does the opposite. You enter input the app should reject, then check that it rejects it well. "Well" means three things at once:

1. The app shows a message a normal person can understand.
2. Nothing crashes, and no internal detail leaks to the screen.
3. The user's other work stays on the page, so they do not retype everything.

An app can reject bad input and still fail. If you type a 1000-character name and the page returns 500 Internal Server Error, the rejection worked and the experience did not.

How to use these checklists

Run each list on staging, such as https://staging.example.com, with a throwaway account like [email protected]. Open the browser console before you start, because errors that happen earlier are lost.

For every item, record two lines:

• Expected: Inline message under the field: "Name must be 100 characters or fewer."
• Actual: Page went blank. Console shows TypeError: Cannot read properties of undefined (reading 'email').

That is enough for a developer to start work.

Authentication and login

Login is the first door, so it gets the most abuse.

1. Submit the form with both fields empty. Expect two inline errors, not one generic banner.
2. Enter a valid email with a wrong password five times in a row. Expect rate limiting or a lockout, and check whether the message changes after the limit.
3. Enter an email that does not exist. Expect the same wording as a wrong password, so the app does not tell strangers which accounts exist.
4. Enter admin' OR '1'='1 as the email and anything as the password. Expect a normal validation error, never a login and never a database error on screen.
5. Enter whitespace only (press the space bar three times) in both fields. Expect the same errors as empty fields.
6. Enter a password with leading and trailing spaces, such as Sunrise-2026 . Decide the rule first, then check the app follows it every time, including at sign-up and at password reset.
7. Enter an email with a plus sign, such as [email protected]. This is valid. Expect it to be accepted at sign-up, login, and reset.
8. Paste a 1000-character string into the email field. Expect a length error, not a request that hangs for 30 seconds.
9. Log in on two tabs, log out in one, then act in the other. Expect a clean redirect to the login page.
10. Change the URL to a page that needs an account while logged out, such as /settings/billing. Expect a redirect, not a partly rendered page.

A common failure here: the app trims spaces from the password at login but not at sign-up. The user creates the account with Sunrise-2026 and can never log in again.

File upload

Uploads touch storage, memory, and often a third-party service, so they break in interesting ways.

1. Upload a file with the wrong type, such as notes.txt where only images are allowed. Expect a message naming the allowed types.
2. Rename virus.exe to photo.jpg and upload it. Expect the app to check the file contents, not just the name.
3. Upload a file larger than the limit, for example a 40 MB image where the cap is 5 MB. Expect the limit in the message: "Files must be under 5 MB."
4. Upload a 0-byte file. Expect a clear rejection, not a saved empty attachment.
5. Upload a file whose name is 300 characters long, or holds accented letters and a pasted emoji, such as réçu-final.pdf. Expect a readable saved name.
6. Start a large upload, then close the tab halfway. Expect no half-saved record in the list.
7. Upload 20 files at once when the limit is 10. Expect a count error before anything uploads.
8. Upload the same file twice. Decide whether duplicates are allowed, then check the behaviour matches.
9. Turn off your network mid-upload. Expect a retry option and a message, not a spinner that never ends.

Search

Search feels safe because nothing gets saved. It still fails often, and it fails in front of everyone.

1. Search for an empty string. Expect either no action or the full unfiltered list, never a crash.
2. Search for whitespace only. Expect the same result as an empty search.
3. Search for a term with no matches, such as zzzzqqq. Expect an empty state that says what to do next, not a blank panel.
4. Search for admin' OR '1'='1. Expect zero results and a normal page.
5. Search for <script>alert(1)</script>. Expect the text to appear escaped in the results header, never to run.
6. Search for a 1000-character string. Expect a limit, not a timeout.
7. Search for a term with an accent or a pasted emoji, such as café. Expect matches on both café and cafe if your rules say so.
8. Search, then press the browser back button. Expect your query and filters to still be there.
9. Type quickly and delete, five times in a row. Expect the results to match the final query, not an older one that arrived late.

Payment and checkout

Money bugs are the expensive kind. Use your payment provider's test cards.

1. Enter the declined test card 4000 0000 0000 0002. Expect a clear message and the form still filled in.
2. Enter the expired card 4000 0000 0000 0069. Expect "This card has expired", not "Payment failed."
3. Enter an expiry date in the past, such as 01/2020. Expect an inline error before the request is sent.
4. Enter a card number one digit short. Expect a format error, not a server round trip.
5. Set the quantity to -1, then to 0, then to 99999. Expect a rejection each time, and check the order total never goes negative.
6. Apply an expired or fake discount code such as SUMMER2019. Expect a rejection, and check the total does not change.
7. Double-click the pay button. Expect one charge. This is the single most valuable negative test on this list.
8. Pay, then press back and submit the form again. Expect no second charge.
9. Remove the last item from the cart during checkout in a second tab, then pay in the first. Expect a clear conflict message.
10. Disconnect the network right after pressing pay. Expect either a completed order or no order, never a paid order with no record.

Account settings

Settings pages save data straight to the profile, so bad input here spreads everywhere.

1. Save an empty name. Expect a required-field error.
2. Save a name of 1000 characters. Expect a limit, and check that the header does not stretch across the page afterwards.
3. Save a name that is spaces only. Expect the same error as empty.
4. Save a name with a pasted emoji after it, such as Ana Ruíz. Decide the rule, then check the profile, the invoice, and any email agree.
5. Change your email to one that already belongs to another account. Expect a clear conflict message.
6. Change your email to [email protected]. Expect it to be accepted and to receive mail.
7. Change your password to your current password. Expect either acceptance or a clear rule, not a silent no-op.
8. Change a setting, then press back without saving. Expect a warning about unsaved changes.
9. Delete your account with an active subscription. Expect a warning that names the consequence.

Reporting what you break

The value of a negative test is lost if the report says "validation is broken". Give the exact input, the expected result, and the actual result, plus the console error if there was one. Tools such as Crosscheck capture the screenshot, console output, and network requests with the report, so the evidence for a crash is attached before you start typing.

Error message wording is part of the test. Compare these:

If the message does not tell the user what to change, the test failed even though the app rejected the input.

Frequently asked questions

How is negative testing different from security testing? They overlap but are not the same. Negative testing checks that wrong input fails safely, while security testing tries to prove an attacker can gain access or read data they should not.

Should I automate these checks? Automate the ones tied to money and access first, such as double-clicking pay and the login lockout. The rest work well as a manual pass before each release.

Is an inline message better than a banner at the top? Yes, for field-level problems. An inline message next to the field tells the user exactly where to look, while a banner makes them hunt through the form.

What if the app accepts a 1000-character name and nothing breaks? Check the places that display it later, such as the header, invoices, and emails. Storage rarely fails first; layout does.

How long should a negative testing pass take? About 30 to 45 minutes per component once you know the app. Keep your inputs in a text file so you can paste them instead of typing them.