Negative Testing: Examples and Test Cases (2026)
A password field accepts 3,000 characters and returns a stack trace. The happy-path test passed, so nobody noticed. Negative testing is the practice of deliberately giving a system invalid input, an unexpected state, or a failing dependency, then checking that it refuses, recovers, or reports the problem correctly. Put simply, it is the part of your suite that asks what the product must not do. The published evidence for its value is thinner than most guides admit. This piece gives you cases to write today, ties each expected result to a requirement where one exists, and says plainly where the public record stops.
Key negative testing statistics for 2026
Only one published measurement of what negative test cases do turned up: a 2013 industrial experiment.
29% of the test cases written were negative, and those negative cases revealed 71% of all defects found by all test cases in the experiment. Population: test cases and defects produced by volunteer developers at one company, Infosys Ltd. (India), randomly assigned to test-driven development, TDD with negative testing, or test-last development. Period: reported at XP2013, 2013. Source: XP2013 programme abstract, "Effects of Negative Testing on TDD: An Industrial Experiment", by Causevic, Shukla, Punnekkat and Sundmark. Evidence type: the authors' reported result from a single controlled experiment.
A "positive test bias": the same abstract reports a shortage of negative test cases under a test-driven development approach. Population and period as above.
No current, independent benchmark of how often negative tests find defects, or of how that varies by platform, appears in the public sources reviewed. The eight competing guides reviewed publish no quantity about negative testing at all. The figures in the later sections are standards, platform rules and policy thresholds. They define what a correct negative result looks like. They do not measure how much negative testing finds.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
Positive vs negative testing: the split that decides what you write
A positive test checks that the system does what the requirement says when given valid input. A negative test checks that it refuses what the requirement forbids when given invalid input, an impossible state, or a failing dependency. A suite made only of positive cases can pass on a build that accepts a blank email address.
A common rule of thumb follows: write at least one positive and one negative case per requirement. The TechTarget explainer on positive vs negative testing states it as a practitioner guideline. Treat it as a default, not a law. If you need the structure of a case itself, the guide on how to write test cases covers it; this article stays on what to put in the negative ones.
Negative test cases for input validation
Each row gives the input or state, the expected result, and the requirement it checks. Where no requirement is cited, the expected result is a default you should confirm against your own product contract.
Case | Input or state | Expected result | Requirement checked |
Empty required field | Submit the form with the name field blank | Form is not submitted; the field is identified and the error is described in text | WCAG 2.2 SC 3.3.1 Error Identification, applies when the error is automatically detected |
Suggestion on a sensitive field | Enter an invalid password or card number | Error is shown, but no hint reveals valid credentials or card data | WCAG 2.2 SC 3.3.3 Error Suggestion, exception where a suggestion would jeopardise security |
Irreversible submission | Submit a payment or account deletion | User is asked to confirm, or the action is reversible or checked | WCAG 2.2 SC 3.3.4 Error Prevention, only on legal, financial, or data-modification pages |
SQL metacharacters in a search field | Enter | No data outside the search scope is returned; the input does not alter the query | OWASP WSTG v4.2 §4.7.5 Testing for SQL Injection |
Script in a stored field | Save a name containing a script tag, then view it from another session | Script does not execute on render | OWASP WSTG v4.2 §4.7.2 Testing for Stored Cross Site Scripting |
Missing required API field | POST without | 400 response with a field-level message | Your API contract; the QAPractices template below has a worked example |
WCAG is an editor's draft, and it is web guidance. The text used here is the W3C Editor's Draft of WCAG 2.2, not the published Recommendation. For web surfaces these criteria are the requirement. For native mobile screens, treat them as a well-specified default that you justify per case.
SC 3.3.1 applies only when the product detects the error. If your app does not validate a field until the server responds, the criterion sets no expectation for the client-side case. Write the server-side case against your own contract.
The security exception in SC 3.3.3 is the one most suites miss. The criterion requires suggestions where corrections are known "unless it would jeopardize the security or purpose of the content." On login, password and payment fields, a helpful "did you mean" hint can leak valid credentials or card data. The negative case there should assert a clear message that reveals nothing useful to an attacker.
Security cases map to named test IDs. The OWASP Web Security Testing Guide v4.2, section 4.7 Input Validation Testing lists reflected and stored XSS, HTTP verb tampering, HTTP parameter pollution and SQL injection as separate tests. Its subtopics also cover other data-layer technologies, so name the one you actually test. Put the ID in the test name so the case traces to a documented method.
The QAPractices REST API negative testing template is a usable starting point. Its worked rows include an empty name returning 400 with a required-field message. Its status codes are examples; your contract decides the correct code. For mobile-specific API testing, see the guide to API testing for mobile teams.
Negative test cases for authentication, permissions and sessions
These are the cases to write:
Wrong credentials. Valid username, wrong password. Expected: a generic failure message, no hint whether the account exists, no stored session.
Lock-out after repeated failures. Fail past your documented threshold. Expected: the account is locked or throttled as specified, and the state persists across app restart.
Expired session. Let the session expire, then tap an action that needs authentication. Expected: the user returns to sign-in and no action is partially applied.
Permission refused. Deny camera or location when first asked. Expected: the dependent feature shows a stated fallback, and the app neither crashes nor re-prompts in a loop.
Permission dismissed rather than denied. On Android 13 and later, Google's notification permission guide lists three user actions: allow, don't allow, and swiping the dialog away without pressing either button. Dismissal is a separate case from denial, with different state to assert. Expected: the app does not record a denial unless your design says so.
Re-prompt asymmetry by target SDK. The same guide says that for apps targeting Android 12L or lower, one tap of "Don't allow" suppresses re-prompting until uninstall and reinstall or an app update. Write one case per target SDK you support, because the branches behave differently.
Revoked mid-session. Revoke a role or permission while the user is on a protected screen. Expected: the next action is refused with a clear state, not a silent failure. TestDevLab's revoked-access scenario covers an authorisation role; an operating-system permission revoked in settings is a second case. Write both.
Biometric failure. Fail the fingerprint or face check repeatedly. Expected: a password fallback is offered, and failed attempts count against your documented policy.
The same Google guide publishes ADB commands for simulating these permission choices and upgrade sequences "without needing to reset your test device." That makes cases 4 to 6 repeatable on a shared device lab instead of dependent on someone tapping a prompt by hand.
Negative test cases for mobile device state
The sampled competitor guides cover web surfaces and generic connection drops. Operating-system-enforced conditions get little space. Each expected result below is a contract question, not a platform guarantee.
Process death and restore. Android states that cached processes "can be killed by the system at any time" and that apps should stop work while cached. Two consequences for your test:
onDestroy()is not guaranteed to run when the system kills the process, so no expected result should depend on it.State you expect to survive must live somewhere that survives. Android's saved UI state guidance separates a ViewModel, which is destroyed on system-initiated process death, from saved instance state and persistent storage.
The expected result: after process death and restore, the app does not lose data your product contract promises to persist, does not show stale state as current, and does not repeat a payment whose server-side status is already settled. Check the server status, not the screen. Write a separate force-stop case, since a user force-stopping the app is a stronger condition than the system killing a background process.
Network transition mid-request. Start a submission, then switch from Wi-Fi to cellular or enable airplane mode before the response returns. Expected: the request completes once or is retried in a way your design permits, the user's input is preserved, and the UI shows success only if the server confirmed. Apple's NWPathMonitor documentation covers network path changes on iOS if you need the hook.
Airplane mode and low storage. Enable airplane mode during a sync, and fill device storage during a download. Expected: the failure is reported, partial files are not presented as complete, and the next launch recovers without manual cleanup.
Backgrounding during upload. Background the app mid-upload. Expected: the upload resumes or fails with a retry path, and the user is never told it completed when it did not.
Locale and timezone change. Change timezone or locale around a scheduled action or date field. Expected: stored times are not silently shifted and locale-dependent validation still applies.
Negative test cases for API and backend responses
When the app talks to a backend, the negative cases shift to the response. For each, ask what the app must never do: crash, silently succeed, or lose the user's input.
Malformed JSON. The server returns a truncated body. Expected: a recoverable error, and the user's input is kept.
Wrong type. A numeric field returns a string. Expected: no crash on parse; the value is rejected or handled as defined.
Unexpected null. A required object is null. Expected: a defined empty or error state, not a blank screen.
Oversized payload. A response or upload exceeds your documented limit. Expected: a size error, shown before the request is sent where possible.
4xx and 5xx handling. Return 401, 403, 404, 429, 500 and 503 in turn. Expected: each maps to a defined user message and retry behaviour, and no 5xx is shown as success.
These cases sit close to a new standards category. OWASP Top 10:2025 A10, Mishandling of Exceptional Conditions, is described as a new category for 2025 containing 24 CWEs and focused on improper error handling, logical errors and failing open. Use it to name the failure class in your test titles: a case that fails open on a 5xx belongs there.
What negative testing actually finds
The one measured answer is the XP2013 experiment from the statistics section: negative cases were 29% of the test cases written and revealed 71% of the defects found by all test cases in that study. The abstract does not give a sample size, task or defect-counting method, and the full paper sits behind a publisher wall, so cite it as a single-company controlled experiment from 2013. It is not a production failure rate and not a figure for your app.
Three published facts sit around it. They give context and consequence, and none measures negative-testing yield.
Input validation remains a ranked weakness. The 2025 CWE Top 25 ranks CWE-20 Improper Input Validation at number 18, with a score of 4.09 and two entries in CISA's Known Exploited Vulnerabilities catalogue, down six places from number 12. The ranking is a severity and prevalence composite, not a test-failure count.
Platform stability thresholds exist. Google Play's technical quality requirements set stability thresholds for published apps. The page does not link any threshold to untested negative paths.
Standards define the expected result. WCAG, the WSTG and the OWASP Mobile Application Security Testing Guide supply checkable expectations for many negative cases. Map each case to a specific control or test, not to the index. They make a case defensible; they do not show how often it finds a defect.
Methodology and limits
The XP2013 figures come from the programme abstract. The abstract reports no sample size, task or defect-counting method, so none is given here. No other comparable measurement of the negative and positive defect split turned up in the sources reviewed.
Vendor opt-in rates are excluded. Batch's 2025 benchmark covers push, in-app, web push and email across its own customer base, July 2024 to July 2025. Its notification opt-in rates do not generalise to camera, location or storage permissions, and non-opt-in is not active refusal.
WCAG as an editor's draft defines expected results for web error handling. It says nothing about native mobile behaviour and does not measure how often errors occur.
Failure-cause breakdowns. No verified published breakdown of mobile app failures by cause (lifecycle timing, permission state, process-death recovery, network transition, layout) was found. Academic Android crash studies exist, but their full text could not be read, so none is reported.
First-party data. No Quash data covers the frequency or yield of negative tests. Settling it would take an original measurement: run a fixed set of negative cases against a defined set of open-source Android apps and record which fail and why. Until someone runs that and publishes the method, the gap stands.
Conclusion
Start with the input validation and permission cases, because their expected results are the easiest to source. Then spend the rest of your effort on device-state cases, which most guides skip and which depend on your product contract. For each case, name the requirement it checks. If you cannot, decide what the product must do first, then write the test.
Continue reading
More articles from the Quash editorial desk.
