Negative Test Cases: 30 Examples

Invalid data, broken state, and missing permissions are where products silently corrupt records or open privilege holes. Negative test cases define the invalid condition, the exact action, and the protective outcome: clear errors, no silent writes, and no accidental access.

This guide gives you 30 practical negative test cases across login, forms, checkout, file upload, API style behavior, roles, and session state. You will also learn how to design negative cases, how they differ from positive and boundary tests, common mistakes, and a checklist you can reuse on any feature. If you still need the full writing workflow, start with how to write test cases.

What Are Negative Test Cases?

Negative test cases are checks designed around invalid, incomplete, unauthorized, or unexpected conditions. The tester intentionally violates a rule or assumption and verifies that the system responds correctly.

Examples of invalid conditions:

• Wrong password
• Missing required field
• Unsupported file type
• Expired coupon
• Guest user opening an admin page
• API call without a token
• Duplicate form submission
• Out of range quantity

Negative testing is not chaos for its own sake. It is structured risk thinking. You ask: what happens when a user, system, or attacker does something the happy path never shows?

A negative test still has a positive quality goal. The product should fail gracefully. That means:

• Reject the action when required
• Preserve data integrity
• Show a useful and safe message
• Log enough for support and debugging
• Avoid leaking sensitive information
• Keep the user in a recoverable state

If a wrong password attempt crashes the page, that is not "good failure." If an unauthorized user sees another account's data, that is a severe defect. Negative cases exist to catch those outcomes.

Why Negative Testing Matters

Most teams over-invest in happy paths. That is understandable. Stakeholders care about whether checkout works, login works, and search returns results. But many production defects live outside the happy path.

Common production failures that negative testing would have caught:

• Form accepts blank required fields and creates incomplete records
• Expired reset links still change passwords
• Coupon can be applied twice after refresh
• User can open another customer's invoice by changing an ID
• Upload accepts executable content disguised as an image
• API returns 200 with an empty body instead of a clear validation error
• Locked account can still authenticate through a secondary endpoint

Negative cases protect trust. Users forgive a missing feature more easily than a silent data loss, a confusing error, or a security leak.

Negative cases also improve design conversations. When a tester asks, "What happens if the payment succeeds but the order write fails?" the team often discovers missing requirements. That question is a form of negative design review.

Positive vs Negative vs Boundary Cases

These three categories work together. Do not treat them as competitors.

Type	Goal	Example
Positive	Valid path works	Login with correct email and password
Negative	Invalid path is blocked safely	Login with wrong password
Boundary	Edge of allowed range behaves correctly	Password with exact minimum length

A boundary can be positive or negative depending on the rule. If the minimum password length is 8:

• 8 characters is a positive boundary
• 7 characters is a negative boundary

Use boundary value analysis and equivalence partitioning when ranges, formats, and categories drive the rules. Use negative cases when the action itself is invalid, unauthorized, or incomplete.

How to Design Negative Test Cases

Step 1: Start From the Rule

Every good negative case begins with a rule or assumption.

Rule: Email is required and must be a valid format.

Negative ideas:

• Empty email
• Spaces only
• Missing @
• Missing domain
• Extra characters that break parsing
• Extremely long email if length is limited

Step 2: Identify Actors and Permissions

Ask who should not be able to do the action.

• Guest vs registered user
• Free plan vs paid plan
• Standard user vs admin
• Owner vs non owner of a resource
• Service account with limited scope

Permission negative cases are often higher value than random invalid strings.

Step 3: Identify State Violations

State based negatives are powerful:

• Using an expired token
• Editing a cancelled order
• Submitting a form twice
• Acting after logout
• Using a reset link after success
• Paying for an out of stock item that was available at add to cart time

These cases catch race conditions, stale UI, and incomplete lifecycle handling.

Step 4: Decide the Expected Protective Behavior

For each negative case, define:

1. What is blocked
2. What message, code, or UI state appears
3. What data does not change
4. What the user can do next
5. Whether security or privacy constraints apply

Step 5: Prefer Realistic Invalid Paths

Random keyboard spam can be useful for stress or fuzzing, but most product defects come from realistic mistakes:

• User pastes an extra space
• User selects the wrong file type
• User reuses an old password against policy
• Support agent opens a deep link with an outdated ID
• Integration sends a null field

Design negative cases that match real users and real systems.

Negative Test Case Template

Field	Example
ID	TC-AUTH-N-012
Title	Verify login fails with wrong password
Type	Negative
Priority	High
Preconditions	Active user exists
Test Data	valid email, incorrect password
Steps	Open login, enter email, enter wrong password, submit
Expected Result	Generic invalid credentials message, no session created, failed attempt recorded per policy
Notes	Do not reveal whether email exists if policy forbids enumeration

Copy friendly version:

Test Case ID:
Title:
Type: Negative
Priority:
Preconditions:
Test Data:
Steps:
  1.
  2.
  3.
Expected Result:
  - Action blocked or rejected
  - Exact message/status
  - Data state unchanged
  - Safe recovery path
Actual Result:
Status:

30 Negative Test Cases With Examples

The following cases are written so you can adapt them to your product. Each includes the invalid condition and a strong expected result pattern.

Authentication and Account Access (1-8)

1. Empty password on login

• Invalid condition: Password field left blank
• Expected: Required field validation appears, authentication is not attempted, no session is created

2. Wrong password

• Invalid condition: Correct email, incorrect password
• Expected: Generic invalid credentials message, no session, failed attempt counted if policy exists

3. Unknown email or username

• Invalid condition: Account does not exist
• Expected: Safe rejection message that matches policy on user enumeration, no privileged data exposed

4. Locked account login attempt

• Invalid condition: Account already locked after failed attempts
• Expected: Login remains blocked, lockout messaging is clear, support or unlock path is available if designed

5. Expired password reset link

• Invalid condition: Reset link older than expiry window
• Expected: Reset form is rejected, password is unchanged, user can request a new link

6. Reused password reset link after success

• Invalid condition: Link used once already
• Expected: Second use fails, password remains the newly set value, no second change occurs

7. Access protected page after logout

• Invalid condition: Session ended
• Expected: Redirect to sign in, protected content is not visible, cached private data is not exposed

8. Access admin page as standard user

• Invalid condition: Insufficient role
• Expected: Authorization error or redirect, no admin controls rendered, no admin API data returned

Form Validation and Input Handling (9-16)

9. Required field left empty

• Invalid condition: Mandatory name, email, or address missing
• Expected: Field level error, form not submitted, existing valid fields retained when appropriate

10. Invalid email format

• Invalid condition: user@ or user.example.com
• Expected: Format validation before save, clear message, no partial record created

11. Unsupported special characters where policy forbids them

• Invalid condition: Script tags or disallowed symbols in a text field
• Expected: Input rejected or sanitized per design, no script execution, safe stored value if accepted

12. Exceeding maximum field length

• Invalid condition: 101 characters in a 100 character field
• Expected: Validation error or blocked input, no truncated silent save unless product explicitly defines truncation

13. Pasting leading or trailing spaces into unique fields

• Invalid condition: " qa.user@example.com " when uniqueness and normalization matter
• Expected: Consistent normalization or rejection policy, no duplicate accounts by whitespace tricks

14. Negative number in quantity field

• Invalid condition: Quantity -1
• Expected: Validation error, cart total unchanged, no inventory side effect

15. Zero value where minimum is one

• Invalid condition: Quantity 0 for purchase
• Expected: Rejected with clear message, user guided to valid quantity

16. Future date where only past or present is allowed

• Invalid condition: Date of birth set to next year
• Expected: Validation error, form not saved

Commerce, Payments, and Coupons (17-22)

17. Expired coupon code

• Invalid condition: Coupon past end date
• Expected: Coupon rejected, original price remains, no partial discount applied

18. Coupon applied to ineligible product

• Invalid condition: Category or product exclusion
• Expected: Rejection or explicit non application, totals correct, no silent ignore without feedback

19. Duplicate coupon application after refresh

• Invalid condition: Same coupon reapplied through refresh or double submit
• Expected: Discount applied once only, payable total remains correct

20. Checkout with out of stock item

• Invalid condition: Item became unavailable after cart add
• Expected: Clear stock error before payment capture, no successful paid order for unavailable stock

21. Payment declined card

• Invalid condition: Test card that simulates decline
• Expected: Order not confirmed as paid, user sees recoverable payment failure, inventory and order state stay consistent

22. Editing price in client request

• Invalid condition: Tampered client side amount if exposed
• Expected: Server recalculates trusted price, rejects mismatch, never charges client provided arbitrary amount

Files, Media, and Uploads (23-26)

23. Unsupported file extension

• Invalid condition: .exe or .svg when only .jpg and .png are allowed
• Expected: Upload rejected before processing, clear format message, no stored file

24. File over size limit

• Invalid condition: 11 MB file when limit is 10 MB
• Expected: Size validation error, no partial corrupted upload saved as success

25. Empty file upload

• Invalid condition: 0 byte file
• Expected: Rejected as invalid content, no profile image replaced

26. Renamed malicious extension

• Invalid condition: Executable content uploaded as .png
• Expected: Content type and validation checks reject unsafe file per security design

Permissions, Sessions, and API Style Negatives (27-30)

27. Horizontal privilege attempt

• Invalid condition: User A requests User B invoice by changing ID
• Expected: 403 or equivalent denial, no invoice data returned, event logged if required

28. Missing authentication token on protected API

• Invalid condition: Authorization header omitted
• Expected: 401 Unauthorized, no business data in body, consistent error contract

29. Expired session token used for update

• Invalid condition: Old token after logout or expiry
• Expected: Update rejected, resource unchanged, client prompted to reauthenticate

30. Double submit of create action

• Invalid condition: User clicks "Create order" twice quickly
• Expected: Only one order created, or second request safely recognized as duplicate according to idempotency design

These 30 cases are not a complete suite. They are a pattern library. For each feature, rebuild the same thinking: invalid input, invalid state, invalid permission, invalid timing, and invalid integration data.

Worked Example: Registration Feature

Requirement:

A new user can register with email, password, and full name. Email must be unique and valid. Password must be 8 to 64 characters and include a number. Terms must be accepted.

Scenario list before cases

• Missing email
• Invalid email format
• Duplicate email
• Weak password
• Password too short
• Password too long
• Terms not accepted
• SQL or script payload in name field
• Submit with all fields empty

Sample negative cases

ID	Title	Expected Result
TC-REG-N-01	Empty email	Required email error, account not created
TC-REG-N-02	Invalid email format	Format error, account not created
TC-REG-N-03	Duplicate email	Unique email error, existing account unchanged
TC-REG-N-04	Password 7 chars	Password policy error, account not created
TC-REG-N-05	Password without number	Password policy error, account not created
TC-REG-N-06	Terms unchecked	Terms acceptance required, account not created
TC-REG-N-07	Script in full name	Rejected or safely stored as text, no script execution
TC-REG-N-08	All fields empty	Multiple required field errors, no account created

Notice that each case has one main invalid condition. That keeps failure analysis clean.

Negative Testing for APIs and UI Together

UI and API negative cases should align.

If the UI blocks an empty email, the API should also reject empty email. Client side validation alone is not protection. A user or script can bypass the UI.

Useful pairing:

UI negative	Matching API negative
Blank required field	POST with missing field returns 400
Unauthorized page visit	Request without token returns 401
Forbidden admin screen	Request with user token returns 403
Invalid format message	Schema validation error body

When UI and API disagree, you have found a product risk, not only a test idea.

How to Write Expected Results for Negative Cases

Weak expected result:

Error should be shown.

Strong expected result:

1. Form is not submitted.
2. Email field shows "Enter a valid email address."
3. No user record is created.
4. Password field retains masked input.
5. Focus moves to the first invalid field.

For API style checks:

1. Response status is 400.
2. Error code is VALIDATION_ERROR.
3. Message identifies the email field.
4. No database row is inserted.

Specific expected results make review possible and reduce arguments during execution.

Prioritizing Negative Cases

Not every invalid idea deserves the same depth.

High priority usually includes:

• Authentication failures
• Authorization bypass attempts
• Payment and money paths
• Data loss or corruption risks
• Privacy exposure
• Destructive actions
• Compliance related validation

Medium priority often includes:

• Format validation for less critical fields
• Helpful error copy quality
• Secondary workflow edge cases

Lower priority may include:

• Extremely exotic inputs with low likelihood and low impact
• Cosmetic inconsistency in error wording

Use risk, not creativity contests, to decide depth.

Negative Cases in Smoke, Sanity, and Regression

Negative cases belong in different suites for different reasons.

• Smoke: usually minimal negatives, maybe one auth failure or one critical validation
• Sanity after a fix: negatives directly related to the bug and nearby rules
• Full regression: high value negatives for money, auth, permissions, and known fragile areas

If you need the broader suite distinctions, read smoke vs sanity vs regression testing.

A common anti-pattern is stuffing dozens of low value format negatives into smoke. That slows builds without protecting the most important risks.

Turning Negative Failures Into Bug Reports

When a negative case fails, the bug report must show why the protective behavior is wrong.

Include:

• The rule that was violated
• Exact invalid data
• Expected rejection behavior
• Actual unsafe or unclear behavior
• Impact: data corruption, security, blocked user recovery, bad UX
• Evidence: screenshot, response body, logs, account state

If the system accepts a blank required field, say what incomplete record was created. If an unauthorized page loads, capture the sensitive data shown. For structure and tone, use how to write a bug report.

Common Mistakes With Negative Test Cases

Mistake 1: Random invalid data with no expected result

Typing !@#$% into every field is not a strategy. Without a rule and expected result, the case is noise.

Mistake 2: Only testing UI validation

If API, batch jobs, or admin imports bypass the UI, negative cases must follow those entry points too.

Mistake 3: Revealing too much in expected security messages

A case that expects "Email not found" may conflict with anti enumeration policy. Align expected results with security design.

Mistake 4: Mixing five invalid conditions in one case

If email is invalid, password is weak, and terms are unchecked, a single failure is hard to interpret. Split them.

Mistake 5: Ignoring state based negatives

Many serious bugs are not bad strings. They are expired links, double submits, cancelled orders, and stale sessions.

Mistake 6: Treating any error message as a pass

An error that crashes the page, loses form data, or exposes stack traces is still a defect.

Mistake 7: Never promoting high value negatives into automation

Stable auth denials, validation contracts, and permission checks are excellent automated regression candidates.

Mistake 8: Forgetting recovery

Negative testing should confirm users can recover: correct the field, request a new link, try another payment method, or contact support. A dead end error can be as bad as a wrong success.

Negative Testing Checklist

Use this before you call a feature "covered":

• Required field absences are covered
• Format and type violations are covered
• Boundary invalid values are covered
• Duplicate and replay actions are covered
• Expired and cancelled states are covered
• Role and ownership denials are covered
• Missing and invalid auth tokens are covered
• Payment and pricing tamper paths are considered
• File type and size rejects are covered where uploads exist
• Error messages are specific, safe, and recoverable
• Data remains unchanged after rejection
• API and UI rules match
• High risk negatives are marked for regression
• Failures can be turned into clear bug reports

Practice Path on QABattle

Reading examples helps, but writing your own is better. Open a manual challenge in the battle arena and force yourself to list only negative paths for ten minutes. Then convert the best five into formal cases with data and expected results. Compare whether your negatives catch validation gaps, permission gaps, or state gaps.

If you are building long term skill, create a personal library:

• Auth negatives
• Form negatives
• Money negatives
• File negatives
• Permission negatives
• Session negatives

Reuse the library whenever a new feature appears. Adaptation is faster than starting from zero.

Final Workflow for Negative Cases

1. Read the requirement and list rules.
2. Mark assumptions about roles, state, timing, and integrations.
3. Brainstorm invalid input, invalid state, and invalid permission ideas.
4. Prioritize by risk.
5. Write focused cases with exact data.
6. Define protective expected results, not only "error."
7. Execute and record evidence.
8. File precise defects when protection fails.
9. Add high value negatives to regression.
10. Review whether UI and API behavior stay aligned.

Negative testing is how a team proves the product is resilient, not only demonstrable in a sales walkthrough. The happy path shows what the product promises. Negative cases show whether that promise stays safe when reality gets messy.

If you remember one rule, remember this: a useful negative test case proves the system rejects the wrong thing in the right way. Clear rejection, safe data, and recoverable next steps are the real pass criteria.