Negative and Boundary Value Testing for APIs with Real Examples

Any developer can make an API work with perfect input. Your job as a tester is to find what happens with everything else: the empty field, the age of 17, the price of minus one, the 5 MB name, the emoji, the duplicated key. This is where most API bugs and many security issues live. In this lesson you’ll learn a systematic method for negative and boundary testing, and run more than 40 real cases against a live validation endpoint.

Why Negative Testing Matters So Much

• Users make mistakes, old app versions send old formats, partner systems send surprises, and attackers send everything.
• Correct rejection protects data integrity: a bad request must not half-save.
• Clear error messages reduce support tickets and help front-end developers show the right field error.

The Validation Endpoint We’ll Test

POST /validate/user on the practice API validates a user payload without saving it. Its rules:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"A","email":"asha@","age":"30","role":"manager","salary":1}' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

One request, five errors, all reported together with the field name. That’s the behaviour to expect (and to ask for) from any API.

Technique 1: Boundary Value Analysis

Developers commonly write < where they meant <=. Boundaries catch those off-by-one bugs.

Other boundaries to look for in real APIs: dates (today, past, far future, Feb 29, time zones), list sizes (0 items, 1, max items in a cart), money (0, 0.01, max transaction limit), file sizes and counts (5th vs 6th saved address).

Technique 2: Equivalence Partitioning by Data Type

For each field, test one value from every “class” of wrong input:

Do the same for strings (empty, spaces only, very long, Unicode, emoji, HTML, SQL), enums (wrong value, wrong case “Admin”), and formats (email without domain, phone with country code, date in the wrong format).

Technique 3: Structural (Request-Level) Negative Tests

These break the request itself, not one field:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '[{"name":"Asha"}]' \
  "https://sqatools.in/wp-json/sqa-api/v1/validate/user"

Technique 4: Cross-Field and Business Rule Violations

• min_price greater than max_price: the practice API returns 400 “min_price cannot be greater than max_price”.
• End date before start date in a booking.
• Coupon valid only above Rs 500 applied to a Rs 499 cart.
• Delivery pincode outside the service area.
• Body id different from the URL id in a PUT (practice API: 422).
• Transfer amount above the account balance or the daily limit.

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/products?min_price=5000&max_price=100"

Technique 5: Special Characters, Unicode and Injection Strings

What a Good Error Response Looks Like

{
  "error": {
    "status": 422,
    "code": "validation_failed",
    "message": "2 field(s) failed validation.",
    "details": [
      { "field": "age",   "message": "age is required: a whole number from 18 to 100 (not a string)." },
      { "field": "phone", "message": "phone must be a 10-digit Indian mobile number starting with 6-9." }
    ]
  }
}

Check every negative response for:

• The specific status code (not a generic 400 for everything, never 200, never 500).
• A machine-readable code and the field name, so apps can highlight the right input.
• All errors at once, not one per attempt.
• A human-readable message without internals (no SQL, stack traces or class names).
• The same error format on every endpoint.
• No side effects: nothing created, updated, charged or emailed.

Automating 40+ Negative Cases with Playwright

import { test, expect } from '@playwright/test';

const URL = 'https://sqatools.in/wp-json/sqa-api/v1/validate/user';
const valid = { name: 'Asha', email: 'asha@example.com', age: 30 };

type Case = { title: string; body: Record<string, unknown>; status: number; field?: string };

const cases: Case[] = [
  // Boundaries
  { title: 'age 17',  body: { ...valid, age: 17 },  status: 422, field: 'age' },
  { title: 'age 18',  body: { ...valid, age: 18 },  status: 200 },
  { title: 'age 100', body: { ...valid, age: 100 }, status: 200 },
  { title: 'age 101', body: { ...valid, age: 101 }, status: 422, field: 'age' },
  { title: 'name 1 char',   body: { ...valid, name: 'A' },            status: 422, field: 'name' },
  { title: 'name 2 chars',  body: { ...valid, name: 'As' },           status: 200 },
  { title: 'name 50 chars', body: { ...valid, name: 'a'.repeat(50) }, status: 200 },
  { title: 'name 51 chars', body: { ...valid, name: 'a'.repeat(51) }, status: 422, field: 'name' },
  // Types
  { title: 'age as string', body: { ...valid, age: '30' }, status: 422, field: 'age' },
  { title: 'age decimal',   body: { ...valid, age: 30.5 }, status: 422, field: 'age' },
  { title: 'age null',      body: { ...valid, age: null }, status: 422, field: 'age' },
  { title: 'name spaces',   body: { ...valid, name: '   ' }, status: 422, field: 'name' },
  // Formats and enums
  { title: 'email no domain',  body: { ...valid, email: 'asha@' },          status: 422, field: 'email' },
  { title: 'unknown role',     body: { ...valid, role: 'manager' },        status: 422, field: 'role' },
  { title: 'phone with +91',   body: { ...valid, phone: '+919876543210' }, status: 422, field: 'phone' },
  { title: 'valid phone',      body: { ...valid, phone: '9876543210' },    status: 200 },
  { title: 'unknown field',    body: { ...valid, salary: 1 },              status: 422, field: 'salary' },
  { title: 'unicode name',     body: { ...valid, name: 'आशा वर्मा' },       status: 200 },
];

for (const c of cases) {
  test(`validate/user: ${c.title} -> ${c.status}`, async ({ request }) => {
    const res = await request.post(URL, { data: c.body });
    expect(res.status()).toBe(c.status);
    if (c.field) {
      const fields = (await res.json()).error.details.map((d: any) => d.field);
      expect(fields).toContain(c.field);
    }
  });
}

test('malformed JSON -> 400 without internals', async ({ request }) => {
  const res = await request.post(URL, { headers: { 'Content-Type': 'application/json' }, data: '{"name": "Asha", ' });
  expect(res.status()).toBe(400);
  expect(await res.text()).not.toMatch(/exception|stack|\.php/i);
});

test('wrong content type -> 415', async ({ request }) => {
  const res = await request.post(URL, { headers: { 'Content-Type': 'text/plain' }, data: 'name=Asha' });
  expect(res.status()).toBe(415);
});

Each row is a test with a readable name in the report, and adding a case is one line.

Negative Testing Checklist

1. Every required field missing, one at a time, and all together.
2. Every field: wrong type, null, empty, too short, too long, boundary values.
3. Every enum: unknown value, wrong case.
4. Every format: invalid email, phone, date, URL, UUID.
5. Body level: malformed, empty, array, oversized, duplicate keys, unknown fields.
6. Headers: wrong or missing Content-Type, Accept, auth.
7. Cross-field and business rules.
8. Unicode, special characters and injection strings.
9. Responses: correct 4xx, clear field errors, no internals, no side effects.

Interview Questions: Negative and Boundary API Testing