How to Write Test Cases for Coupon Codes (With Examples)

How to Write Test Cases for Coupon Codes (With Examples)

How to Write Test Cases for Coupon Codes (With Examples)

Coupon codes are a common feature in e‑commerce, SaaS, and mobile apps. They drive promotions, acquire new users, and encourage repeat purchases. Because they touch pricing, inventory, and user experience, a defect in coupon handling can lead to revenue loss, compliance issues, or frustrated customers. This guide shows you how to design test cases that uncover those risks, from simple positive checks to complex edge conditions that only appear in production. After reading, you will have a concrete test matrix, a clear process for prioritizing and maintaining cases, and practical tips for coupling manual design with autonomous exploration.

1. Understanding Coupon Code Functionality

Before writing any test, you need a shared mental model of what the coupon system does. Most implementations share a core set of concepts, though details vary by platform.

1.1 Core Entities and Attributes

1.2 Typical Flow

1. User enters a coupon code in the cart or checkout page.
2. Front‑end sends the code to a validation endpoint (often /api/coupons/validate).
3. Back‑end checks existence, date validity, usage limits, product applicability, and minimum order value.
4. If valid, the engine calculates discount, updates order totals, and returns the new amount.
5. On order placement, the system records a redemption and decrements any usage counters.
6. If invalid, the system returns an error code (e.g., COUPON_EXPIRED, INVALID_CODE, MIN_ORDER_NOT_MET).

Understanding these steps lets you map each test case to a specific validation or calculation point.

2. Test Case Anatomy

A well‑structured test case makes review, execution, and automation easier. Use a consistent template so that anyone on the team can grasp intent quickly.

2.1 Mandatory Fields

• Test ID – unique identifier (e.g., CPN-001).
• Title – short, descriptive phrase.
• Preconditions – system state required before starting (e.g., “User is logged in, cart contains $120 worth of eligible items”).
• Steps – numbered actions the tester performs.
• Expected Result – observable outcome (UI message, API response, database change).
• Postconditions – any cleanup needed (e.g., “Remove applied coupon from cart”).
• Tags – for filtering (e.g., positive, boundary, security).
• Linked Requirement – reference to the spec or user story (e.g., US-1123).

2.2 Optional but Helpful Fields

• Test Data – specific coupon code, amount, dates.
• Automation Hint – note if the case is suited for UI, API, or contract test.
• Risk Level – low/medium/high based on impact and likelihood.
• Estimated Effort – in minutes, useful for sprint planning.

2.3 Example Template (Markdown)

**Test ID:** CPN-001  
**Title:** Valid percent‑off coupon reduces order total correctly  
**Preconditions:**  
- User authenticated  
- Cart contains two items: $50 + $80 = $130 subtotal  
- Coupon “SPRING10” exists: 10% off, no min order, valid today  

**Steps:**  
1. Navigate to cart page.  
2. Enter coupon code `SPRING10` in the input field.  
3. Click “Apply”.  
4. Observe updated order summary.  

**Expected Result:**  
- Discount line shows $13.00 (10% of $130).  
- New total = $117.00.  
- No error message displayed.  

**Postconditions:**  
- Clear cart or remove coupon to avoid side effects in subsequent tests.  

**Tags:** positive, api, ui  
**Linked Requirement:** US-1123 – Apply percent‑off coupon

Using this structure consistently will make it trivial to export cases to test management tools or generate automated skeletons.

3. Positive Test Cases

Positive cases verify that the coupon works as intended when all conditions are satisfied. They form the baseline confidence that the happy path is solid.

3.1 Simple Percent‑Off

3.2 Fixed‑Amount and Free Shipping

3.3 Stackable Coupons (if allowed)

3.4 Date‑Bound Coupons

3.5 Usage Limits

These positive cases give you confidence that the core discount logic, date checks, and limit enforcement work.

4. Negative and Invalid Input Cases

Negative testing ensures the system gracefully rejects malformed or unauthorized attempts. It also surfaces security gaps such as coupon guessing or tampering.

4.1 Code Format and Existence

4.2 Business Rule Violations

4.3 Tampering and Replay

4.4 Rate Limiting and Abuse

These cases protect against both functional bugs and potential fraud vectors.

5. Boundary and Edge Cases

Boundary testing focuses on limits of numeric fields, date handling, and string lengths. Edge cases combine multiple constraints to reveal hidden interactions.

5.1 Numeric Limits

5.2 Date and Time Edge Cases

| Preconditions | Steps | Expected Result |
|----|--------------------|-------|-----------------|
| CPN-035 | System clock set to 2025-04-15 12:00:00 UTC, coupon valid 2025-04-15 00:00:00 – 2025-04-15 23:59:59 | 1. Apply at 12:00:00 | Discount applied |
| CPN-036 | Same coupon, system clock set to 2025-04-15 23:59:59 | 1. Apply at 23:59:59 | Discount applied |
| CPN-037 | System clock set to 2025-04-16 00:00:00 (one second after end) | 1. Apply | Error `COUPON_EXPIRED` |
| CPN-038 | Coupon uses only date (no time) field, start = 2025-05-01, end = 2025-05-03 | 1. Apply at 2025-05-02 23:59:59 (local timezone) | Depending on implementation, either valid or invalid – test both UTC and local handling |

5.3 String Length and Character Set

5.4 Combined Boundary Scenarios

These edge cases often surface defects in rounding, timezone conversion, or incorrect logical operators (using > instead of >=).

6. Business Rule and Promotion Logic Cases

Beyond simple arithmetic, coupons frequently interact with complex promotional engines: tiered discounts, buy‑X‑get‑Y, referral bonuses, and dynamic pricing.

6.1 Tiered Discounts (Spend‑Based)

6.2 Buy‑X‑Get‑Y (BXGY)

6.3 Referral and Affiliate Codes

6.4 Dynamic Pricing and Personalized Offers

These cases ensure that the promotion engine correctly evaluates eligibility rules, applies the right calculation, and updates any associated counters or rewards.

7. Integration and Flow Test Cases

Coupon behavior does not exist in isolation; it must work across the entire checkout flow, payment gateways, inventory reservation, and order fulfillment.

7.1 End‑to‑End Checkout with Coupon

7.2 Payment Gateway Interaction

7.3 Inventory and Reservation

These flow tests verify that coupon logic integrates cleanly with downstream systems and does not leave the system in an inconsistent state.

8. Automation Strategies and Tooling

Manual test case design is essential, but executing hundreds of variations by hand is inefficient. Combining well‑written cases with automated scripts and autonomous exploration yields both depth and breadth.

8.1 Choosing the Right Automation Layer

A typical strategy: unit tests for the discount algorithm, API tests for validation logic, and a subset of UI tests for the happy‑path and a few error flows. The rest can be covered by autonomous exploration.

8.2 Example: Parameterized API Test in pytest

import pytest
import requests

BASE_URL = "https://api.example.com/coupons"

@pytest.mark.parametrize(
    "code, cart_subtotal, expected_discount, expected_error",
    [
        ("SPRING10", 130.0, 13.0, None),
        ("FLAT10", 30.0, 10.0, None),
        ("MIN50", 40.0, None, "MIN_ORDER_NOT_MET"),
        ("EXPIRED", 100.0, None, "COUPON_EXPIRED"),
        ("", 50.0, None, "COUPON_CODE_REQUIRED"),
        ("!!@@", 20.0, None, "INVALID_COUPON_FORMAT"),
    ],
)
def test_coupon_validation(code, cart_subtotal, expected_discount, expected_error):
    payload = {"code": code, "cart_subtotal": cart_subtotal}
    resp = requests.post(f"{BASE_URL}/validate", json=payload, timeout=5)
    assert resp.status_code == 200
    data = resp.json()
    if expected_error:
        assert data["error"] == expected_error
        assert "discount" not in data
    else:
        assert data["discount"] == pytest.approx(expected_discount, rel=1e-9)
        assert data["new_total"] == pytest.approx(cart_subtotal - expected_discount)

This test covers positive, negative, boundary, and format cases in a few lines. Adding more parametrized rows expands coverage quickly.

8.3 Example: Playwright Script for UI Flow

const { test, expect } = require('@playwright/test');

test('apply coupon reduces total and proceeds to checkout', async ({ page }) => {
  await page.goto('https://shop.example.com/cart');
  await page.fill('[data-test="cart-subtotal"]', '130'); // mock or set via API
  await page.fill('[data-test="coupon-input"]', 'SPRING10');
  await page.click('[data-test="apply-btn"]');

  const discount = await page.textContent('[data-test="discount-amount"]');
  expect(discount).toBe('$13.00');

  const total = await page.textContent('[data-test="order-total"]');
  expect(total).toBe('$117.00');

  await page.click('[data-test="checkout-btn"]');
  await expect(page).toHaveURL(/.*\/payment/);
  const paymentAmount = await page.locator('[data-test="payment-amount"]').innerText();
  expect(paymentAmount).toBe('$102.00'); // assuming tax included elsewhere
});

Such a script can be run in CI on every pull request, giving fast feedback on the coupon UI.

8.4 Leveraging Autonomous Exploration with SUSA

SUSA (SUSATest) can complement the above automated suite by discovering scenarios that were not anticipated in the test plan. After uploading an APK or pointing SUSA at a web URL, the agent:

• Generates personas (curious, impatient, novice, etc.) that interact with the coupon field in varied ways (e.g., pasting long strings, using emoji, rapid double‑tap).
• Explores alternative paths: applying a coupon before logging in, after adding a gift card, or mid‑checkout.
• Detects crashes, ANRs, dead buttons, and WCAG issues that might be triggered by