Positive and Negative Testing

Why it matters

Users mistype, leave fields empty and press Back at the wrong moment; other systems time out. A product that works only on the happy path may lose a user's input after one mistake, answer an invalid request with a server error, or charge a customer twice. These are defects in the code that handles the unexpected, and they reach production when nobody designed a test for them.

Developers usually try the happy path before handing a feature over; the rejection paths are less likely to have been tried, so negative tests uncover much of the hidden risk. Positive tests stay essential: they prove that the feature serves its purpose.

Positive testing and the happy path

A positive test uses valid data and an allowed sequence of actions, and expects success: correct output, correctly stored data and the right side effects, such as a confirmation email. As in the lesson on functional testing, the expected result comes from the test basis, not from whatever the system happens to do.

The happy path is the main scenario in which everything goes as planned: typical data, default choices, no mistakes. Some teams call it the main success scenario. A feature has one happy path but usually several positive tests, because there is more than one valid way to succeed.

• Happy path: a cart of 250.00 SAR and the code SAVE20 (20% off) give a discount of 50.00 SAR and a total of 200.00 SAR.
• Valid variations: save20 in lower case works too, because codes are not case-sensitive; removing the code returns the total to 250.00 SAR.

Try it: Positive Test Generator

Negative testing: invalid input and unintended use

A negative test deliberately gives the system something it should not accept and expects a controlled rejection. The test passes when the system refuses exactly as specified. It fails when the system accepts the input, crashes, or refuses in a harmful way, such as clearing the whole form.

The test basis defines what is invalid; you will meet the same idea as invalid equivalence partitions in the test design module. Look for negative tests in these categories:

• Missing data: an empty required field, an API request without a body.
• Wrong format or type: letters in an amount, an email without @, the date 31/02/2026.
• Out of range: a quantity of 0 or -1.
• Wrong state or order: RAMADAN24 after its end date, paying for an order that is already paid.
• No permission: opening another customer's order, only on systems you own or have written permission to test.
• A failed dependency: the payment provider times out.

Try it: Negative Test Generator Try it: Validation Test Generator

Expected error handling: what a correct rejection looks like

"An error is shown" is not an expected result, because almost any behaviour passes it. Write down the parts of a correct rejection:

At API level, the request below sends the expired code. The test checks the status and the body, and a second request, GET /api/cart, confirms that the total is still 250.00 SAR.

• A specific message, in text next to the field, that says what to fix. Specific is not revealing: a login form says that the email or password is incorrect, not which one.
• No other change: no record created, no money moved, no email sent, and the user's input kept.
• No internal details: no stack trace or SQL error. The OWASP Error Handling Cheat Sheet recommends a generic message for the user and the details in the server log.
• The status code the API contract defines. RFC 9110 uses the 4xx class for errors in the client's request and 5xx for server errors, so invalid data gets a 4xx such as 400 or 422, never a 500.
• Recovery: once the input is corrected, the positive path works without starting again.

POST /api/cart/discount HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{"code": "RAMADAN24"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"error": "code_expired", "message": "This discount code has expired."}

Try it: API Status Code Simulator Try it: Mock Error Response Generator

Worked example: tests for a discount code

Requirement: "At checkout, a customer can apply one discount code. A code works only between its start and end dates and once per customer, and it is not case-sensitive." The cart holds 250.00 SAR of eligible items.

Start with the happy path, then use one invalid condition per negative test, so that a failure points to exactly one rule. In DC-03 to DC-06 the total must stay 250.00 SAR. Designing negative tests also exposes gaps in the requirement, as DC-07 shows.

• DC-01, positive (happy path): SAVE20 → discount 50.00, total 200.00.
• DC-02, positive: save20 → the same result as DC-01.
• DC-03, negative: Apply with the field empty → "Enter a discount code".
• DC-04, negative: NOPE99, which does not exist → "This code is not valid".
• DC-05, negative: RAMADAN24, which ended yesterday → "This code has expired".
• DC-06, negative: SAVE20 a second time by the same customer → "You have already used this code".
• DC-07, open question: WELCOME10 while SAVE20 is applied. Does it replace the first code or is it refused? Ask the product owner before writing the expected result.

Frequently asked questions

References

• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• OWASP Cheat Sheet Series: Error HandlingOWASP FoundationError responses that help the caller without leaking stack traces, versions or internal paths.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.